My point is that the sustainable rate is only theoretical. Think of the situation where no one uses crude oil at all, if that were possible. Some of today's forests and plants will eventually be made into oil in the fullness of time (millions and millions of year). Divide the amount of oil produced by current forests and plants (including plancton) in N years (N being very large) by N and this is the quantity of oil that we can consume every year that is being perpetually renewed.
This is the renewable rate. It is very low, probably something in the thousands of litres per year, proably not a whole lot more.
As an exercise, this highlight how much faster we are expending resources than they are being produced, and that at some point in the future it simply will have to stop.
Thanks, I had never heard of this project before and this is a useful contribution. However that project more or less proves the point that fiddling with the optimization parameters is a waste of time for all but the most CPU-intensive applications.
Over all of the benchmarks, the optimal optimization parameters achieve a runtime gain of 4% over -O3 and 7% over -O2. Note that some of the options used for these gains are a bit frightening, such as "-funsafe-math-optimizations".
For most applications this is not worth worrying about. It might be worth it for the kernel, libc and a few other crucial components, but I cannot see the point of recompiling X or KDE to achieve at best this kind of gain, when the bottleneck is clearly going to be I/O, not CPU.
Also many of these options not being in -O1 or -O2 are not well tested, for reliability purposes I would never use them in production software.
After a certain age it is very likely that the type of connection you refer to would be necessary.
This is from experiments on cats who were forced to wear some kind of optical contraption in front of their eyes from birth that reversed the field of their vision (i.e: everything was upside down). The cats learned to use this type of input and developed normal vision. When the contraption was removed, all cats are very confused for a while, but if cats are young enough at the time of the removal their brain did adjust after a while and they recovered normal vision again. If the cats were too old they remained confused.
If the connections were rewired randomly you'd get basically undecipherable noise from someone who had normal vision before. It's not clear if anyone would adjust. The cat experiment was much simpler with a simple geometry transform rather than random rewiring.
It's not *quite* as simple as that. First of all fast breeder type reactors that can produce plutonium suitable for use in reactors need more cooling than normal reactors. This usually means primary cooling is done with liquid sodium which comes with a lot of problems and special needs.
Then the product of fission must be reprocessed to separate the Plutonium from the rest. This is not completely trivial and usually involves processing in a different location to where the breeder is located. This means transport of highly radioactive material, which no one likes.
All in all it turns out that the economical promises of breeder reactors are actually hard to fullfill. In France (where 80% of the electricity production comes from nuclear plants) they had a breeder program too (called SuperPhoenix), and they've shut it down as well, after safety and economical concerns became overwhelming.
You are correct in saying that breeders can be used to transmute high-level, long half-life wastes, in particular to get rid of Neptunium 237, but even this requires special infrastructure not found anywhere in the West as far as I know.
You need the vector drawing features in the GUI components of the O/S to get things started, but then developing good-looking resolution-independent widgets & icons is actually not trivial at all from the artistic point of view, so the upshot is it is all going to take a while.
There was an article about this very topic on the Fedora newsletter a little while back, but I can't find the article anymore, sorry.
Does your procedure maximize the window or merely un-minimize it? The two are quite different.
Maximizing means (to me at least) making it take over as much of the screen real-estate as the windows manager will let the application. Un-minimizing just means popping it back from the dock to the size the window had before it was minimized.
This things do happen. Maybe it had been driven too hard (it was syncing fine and well within the documented specs though). My wife and I were about to go to the movies when we heard that weird sound in the office room. We got in and nearly choked. The monitor was in flame. It was a cheap 15" KTX brand. I pulled the plug and my wife grabbed a comforter (thick blanket) to wrap around the monitor and stop the fire. The wall was black, some papers were lost and the smoke incredibly toxic, but the rest of the computer was fine and most importantly nothing else caught fire.
Had it happened only 15 minutes later the whole house would have been up in flame for sure.
It took a lot of scrubbing to get the wall to a more normal colour. We still have the blanket (with a big hole in the middle that was later patched by my mum), we use it as a picnic rug now. It has suffered lots of further abuse at the hand of my daughter (crayons left to melt on it in the sun, various drinks poured on it, etc), but it is a well-loved piece of family heirloom now! I still use the PC case and power supply, but the innards have been changed years ago, and I got a nice expensive Sony 17" screen as a replacement (they don't make those anymore).
That was in 1998. I've never bought KTX since and I always turn the screens off by hand when I leave the house or go to bed. Do the same!
Lots can happen in 5 years, but at present the image quality is not great and it's grey-levels only, right now a current PC takes 2 seconds per image to render the correct hologram. At Moore doubling speed it will take more than five years until little embedded processors in cell phones can render @30fps.
Unless a large amount of money gets dumped on this idea look for it in 10 years' time or thereabouts.
Usually when something doesn't get recognized at boot time or for some reason doesn't work it rarely helps to try another distribution, if the one you're using is reasonably up-to-date (Debian stable is right out).
The way to go is to hit Google mentionning your Linux and the hardware that doesn't work, regardless of your distribution.
The reason for this is that the vast vast majority of hardware drivers come with the kernel, and usually the problem you are having has been experienced by someone else, and the solution will be cross-distribution.
The other thing is that each reasonable distro will have a forum of some sort, and it pays to hang on with the one you have now. If you just give up on distribution A and try B probably your problem will be the same under B as it was under A.
Remember that a lot of hardware doesn't have drivers under Linux, the reasons for this are well known. This means you may need to be more flexible with your hardware and accept that you may have to shop around to find something that is in fact supported (thereby rewarding the manufacturers who at least don't make it hard to write drivers for their stuff).
From the way you tell it, it seems that no one is really responsible, even though the outcome is very sad. Can your father be blamed for having an unanticipated medical problem? surely not. Can the company be responsible for an accident they had no direct involvement in? If the company followed accepted OH&S practices, then no. However presumably the victim had no other course of action than to sue someone to get some sort of compensation.
This sounds like a screwy adversarial system at work here. No one is really benefiting other than the fat cats in the legal system, I'd say.
It is possible to prove mathematically that what you are trying to describe is simply impossible at compile time. It is equivalent to the stopping problem, demonstrated to be unsolvable in 1936 by Alan Turing.
The only way to reliably detect leaks and other memory-related problems is at run time by running the program in a controlled environment. This is why VM can do it (java, C#, most script languages) and not native code compilers. For C/C++ programs you have to use a tool like valgrind or purify.
And even then, you can only detect the leaks that happen to be generated by a particular run of the program. There is no way to statically check a program for leaks and be assured that you've found them all.
You are 100% correct. Even today the ISO C++ library uses char* almost everywhere instead of std::strings. You have to use char* to open file streams for example.
This has got to be one the least of the problems the new Iraqi government is facing right now.
Let's see: the new gov has a legitimity problem, a lot of people want to blow them up, neighbours are considering making things even harder, they have to justify a continued US presence to a skeptical population, they have to organize free elections in a country racked by terrorism, and hmm, oh yes, their web site is on a.org domain somewhere instead of.iq
First of all BSD people make use of GPL products a gread deal. AFAIK gcc is still the compiler of choice for all the BSDs. It's not as if GPL people never give anything back.
I sometimes wonder if the world would have been different if the *BSD had become Free earlier than Linux. As it is more developers use the GPL over the BSD license. Is that an artifact of the most popular Unix-like kernel license, or do more people really believe the FSF than they believe the BSD people? I don't know.
Personally I have my own Free software project (http://imview.sf.net) and I've released it under the GPL. I did this partly so that people who want to include parts of it in different, non-GPL projects ask my permission first (so far always given). I wouldn't want my work to participate indirectly in things I don't approve of. Call me paranoid if you want. In larger projects this is not a workable approach of course, but it does illustrate the fact that just because a whole piece of software is GPLed it necessarily means it has to be that way for all time and for all people.
> If you believe that you get plenty, if not more, > useful contributions with the BSD license, [...]
In your own words, BSD licensing is being idealistic here. Here's free stuff, use it, do what you want, do the right thing.
There is nothing wrong with being idealistic. In fact a lot of things are being done through idealism.
> That means that in some cases, the GPL will > actually prevent people from doing the right > thing (using open source code and giving back > code).
Similarly but in different contexts, the GPL will actually ensure that people are doing the right thing, using open source code and giving back stuff. Without the GLP, no Objective-C in gcc for example, no improvement to KHTML in Konqueror. There are many other examples. The FSF has actually been very successful in ensuring compliance without ever resorting to courts.
Microsoft is starting to give stuff back. Maybe the BSD license works as well in different ways.
The aims are the same. We should stop arguing. Indeed you can't use the BSD license if some of the code you want to use is GPL but that's just what the developers of the code you want to use wanted, to ensure compliance with Free software ideals.
Is it unfair that the GPL camp developers can use BSD code when BSD camp developers can't do the reverse? No. Absolutely not. When a BSD camp developer uses the BSD license this is precisely what they give up, and more. Their code can be used in proprietary software in fact. BSD camp developers cannot complain that their code is being used in ways they don't approve of.
Similarly when BSD developers complain that they can't use GPL code for the reasons above they are being disingenuous. By its very nature the BSD license admits the existence of other ways of distributing software, so they should not complain that it does happen in practice.
It would be much more productive to everybody if the BSD developers expressed happiness about seeing their code used in GPLed products (as well as in proprietary ones), and continue to advocate the BSD license as a license that actually encourages even proprietary developers to do the same thing in practice in practical examples, not just theoretical ones.
Like I said earlier, even Microsoft is starting to release code under BSD-like licenses. I think this might be indication that the BSD camp is doing something right. Is Microsoft doing that of its own volition or because of the widespread percieved threat of GPL software I honestly don't know. This is a question for another day.
In the meantime peace in the F/OSS camps would be absolutely terrific.
Slashdot Mirror
My point is that the sustainable rate is only theoretical. Think of the situation where no one uses crude oil at all, if that were possible. Some of today's forests and plants will eventually be made into oil in the fullness of time (millions and millions of year). Divide the amount of oil produced by current forests and plants (including plancton) in N years (N being very large) by N and this is the quantity of oil that we can consume every year that is being perpetually renewed.
This is the renewable rate. It is very low, probably something in the thousands of litres per year, proably not a whole lot more.
As an exercise, this highlight how much faster we are expending resources than they are being produced, and that at some point in the future it simply will have to stop.
Hi,
Thanks, I had never heard of this project before and this is a useful contribution. However that project more or less proves the point that fiddling with the optimization parameters is a waste of time for all but the most CPU-intensive applications.
Over all of the benchmarks, the optimal optimization parameters achieve a runtime gain of 4% over -O3 and 7% over -O2. Note that some of the options used for these gains are a bit frightening, such as "-funsafe-math-optimizations".
For most applications this is not worth worrying about. It might be worth it for the kernel, libc and a few other crucial components, but I cannot see the point of recompiling X or KDE to achieve at best this kind of gain, when the bottleneck is clearly going to be I/O, not CPU.
Also many of these options not being in -O1 or -O2 are not well tested, for reliability purposes I would never use them in production software.
After a certain age it is very likely that the type of connection you refer to would be necessary.
This is from experiments on cats who were forced to wear some kind of optical contraption in front of their eyes from birth that reversed the field of their vision (i.e: everything was upside down). The cats learned to use this type of input and developed normal vision. When the contraption was removed, all cats are very confused for a while, but if cats are young enough at the time of the removal their brain did adjust after a while and they recovered normal vision again. If the cats were too old they remained confused.
If the connections were rewired randomly you'd get basically undecipherable noise from someone who had normal vision before. It's not clear if anyone would adjust. The cat experiment was much simpler with a simple geometry transform rather than random rewiring.
There is a sustainable rate, but it's very low. Think of the rate at which current forests are being converted to crude oil.
It's not *quite* as simple as that. First of all fast breeder type reactors that can produce plutonium suitable for use in reactors need more cooling than normal reactors. This usually means primary cooling is done with liquid sodium which comes with a lot of problems and special needs.
Then the product of fission must be reprocessed to separate the Plutonium from the rest. This is not completely trivial and usually involves processing in a different location to where the breeder is located. This means transport of highly radioactive material, which no one likes.
All in all it turns out that the economical promises of breeder reactors are actually hard to fullfill. In France (where 80% of the electricity production comes from nuclear plants) they had a breeder program too (called SuperPhoenix), and they've shut it down as well, after safety and economical concerns became overwhelming.
You are correct in saying that breeders can be used to transmute high-level, long half-life wastes, in particular to get rid of Neptunium 237, but even this requires special infrastructure not found anywhere in the West as far as I know.
Also there is the proliferation issue.
You need the vector drawing features in the GUI components of the O/S to get things started, but then developing good-looking resolution-independent widgets & icons is actually not trivial at all from the artistic point of view, so the upshot is it is all going to take a while.
There was an article about this very topic on the Fedora newsletter a little while back, but I can't find the article anymore, sorry.
I'm happy to see the artifact-free result of so much computation. Sure it's blurry but not due to noise. The blur is part of the data in this case.
I agree that the author could post JPG preview images, but getting the current pictures is useful as well.
Yes but at least you don't have to read them. How many emails that you want/have to read do you receive every day?
Does your procedure maximize the window or merely un-minimize it? The two are quite different.
Maximizing means (to me at least) making it take over as much of the screen real-estate as the windows manager will let the application. Un-minimizing just means popping it back from the dock to the size the window had before it was minimized.
This things do happen. Maybe it had been driven too hard (it was syncing fine and well within the documented specs though). My wife and I were about to go to the movies when we heard that weird sound in the office room. We got in and nearly choked. The monitor was in flame. It was a cheap 15" KTX brand. I pulled the plug and my wife grabbed a comforter (thick blanket) to wrap around the monitor and stop the fire. The wall was black, some papers were lost and the smoke incredibly toxic, but the rest of the computer was fine and most importantly nothing else caught fire.
Had it happened only 15 minutes later the whole house would have been up in flame for sure.
It took a lot of scrubbing to get the wall to a more normal colour. We still have the blanket (with a big hole in the middle that was later patched by my mum), we use it as a picnic rug now. It has suffered lots of further abuse at the hand of my daughter (crayons left to melt on it in the sun, various drinks poured on it, etc), but it is a well-loved piece of family heirloom now! I still use the PC case and power supply, but the innards have been changed years ago, and I got a nice expensive Sony 17" screen as a replacement (they don't make those anymore).
That was in 1998. I've never bought KTX since and I always turn the screens off by hand when I leave the house or go to bed. Do the same!
Lots can happen in 5 years, but at present the image quality is not great and it's grey-levels only, right now a current PC takes 2 seconds per image to render the correct hologram. At Moore doubling speed it will take more than five years until little embedded processors in cell phones can render @30fps.
Unless a large amount of money gets dumped on this idea look for it in 10 years' time or thereabouts.
Out of curiosity: which windows manager are you using?
Usually when something doesn't get recognized at boot time or for some reason doesn't work it rarely helps to try another distribution, if the one you're using is reasonably up-to-date (Debian stable is right out).
The way to go is to hit Google mentionning your Linux and the hardware that doesn't work, regardless of your distribution.
The reason for this is that the vast vast majority of hardware drivers come with the kernel, and usually the problem you are having has been experienced by someone else, and the solution will be cross-distribution.
The other thing is that each reasonable distro will have a forum of some sort, and it pays to hang on with the one you have now. If you just give up on distribution A and try B probably your problem will be the same under B as it was under A.
Remember that a lot of hardware doesn't have drivers under Linux, the reasons for this are well known. This means you may need to be more flexible with your hardware and accept that you may have to shop around to find something that is in fact supported (thereby rewarding the manufacturers who at least don't make it hard to write drivers for their stuff).
Yes, "quite a bit" is a little understatement here. How about ./configure scripts taking 5-10 minutes on Cygwin and about 20 seconds on Linux?
Cygwin shell is incredibly slow. Executables compiled with Cygwin are reasonably fast but startup times are horrendous.
You don't have to download them, they are waiting for you at your newsagent.
Currently at mine I can pick up the latest Debian, Fedora, Mandrake et al. for the price of a magazine.
Does Microsoft developer software get distributed in that way too? I haven't seen it so far.
Like Duke Nuk'em Forever?
Can't resist, sorry.
Very useful if you have a teenage daughter.
From the way you tell it, it seems that no one is really responsible, even though the outcome is very sad. Can your father be blamed for having an unanticipated medical problem? surely not. Can the company be responsible for an accident they had no direct involvement in? If the company followed accepted OH&S practices, then no. However presumably the victim had no other course of action than to sue someone to get some sort of compensation.
This sounds like a screwy adversarial system at work here. No one is really benefiting other than the fat cats in the legal system, I'd say.
Yes, and let's rewrite all the known O/S kernels in C# or Java. What a great idea!
It is possible to prove mathematically that what you are trying to describe is simply impossible at compile time. It is equivalent to the stopping problem, demonstrated to be unsolvable in 1936 by Alan Turing.
The only way to reliably detect leaks and other memory-related problems is at run time by running the program in a controlled environment. This is why VM can do it (java, C#, most script languages) and not native code compilers. For C/C++ programs you have to use a tool like valgrind or purify.
And even then, you can only detect the leaks that happen to be generated by a particular run of the program. There is no way to statically check a program for leaks and be assured that you've found them all.
Sorry.
You are 100% correct. Even today the ISO C++ library uses char* almost everywhere instead of std::strings. You have to use char* to open file streams for example.
This has got to be one the least of the problems the new Iraqi government is facing right now.
.org domain somewhere instead of .iq
Let's see: the new gov has a legitimity problem, a lot of people want to blow them up, neighbours are considering making things even harder, they have to justify a continued US presence to a skeptical population, they have to organize free elections in a country racked by terrorism, and hmm, oh yes, their web site is on a
Jeez, which problem should they tackle first?
Thanks for the discussion.
First of all BSD people make use of GPL products a gread deal. AFAIK gcc is still the compiler of choice for all the BSDs. It's not as if GPL people never give anything back.
I sometimes wonder if the world would have been different if the *BSD had become Free earlier than Linux. As it is more developers use the GPL over the BSD license. Is that an artifact of the most popular Unix-like kernel license, or do more people really believe the FSF than they believe the BSD people? I don't know.
Personally I have my own Free software project (http://imview.sf.net) and I've released it under the GPL. I did this partly so that people who want to include parts of it in different, non-GPL projects ask my permission first (so far always given). I wouldn't want my work to participate indirectly in things I don't approve of. Call me paranoid if you want. In larger projects this is not a workable approach of course, but it does illustrate the fact that just because a whole piece of software is GPLed it necessarily means it has to be that way for all time and for all people.
> If you believe that you get plenty, if not more,
> useful contributions with the BSD license, [...]
In your own words, BSD licensing is being idealistic here. Here's free stuff, use it, do what you want, do the right thing.
There is nothing wrong with being idealistic. In fact a lot of things are being done through idealism.
> That means that in some cases, the GPL will
> actually prevent people from doing the right
> thing (using open source code and giving back
> code).
Similarly but in different contexts, the GPL will actually ensure that people are doing the right thing, using open source code and giving back stuff. Without the GLP, no Objective-C in gcc for example, no improvement to KHTML in Konqueror. There are many other examples. The FSF has actually been very successful in ensuring compliance without ever resorting to courts.
Microsoft is starting to give stuff back. Maybe the BSD license works as well in different ways.
The aims are the same. We should stop arguing. Indeed you can't use the BSD license if some of the code you want to use is GPL but that's just what the developers of the code you want to use wanted, to ensure compliance with Free software ideals.
Is it unfair that the GPL camp developers can use BSD code when BSD camp developers can't do the reverse? No. Absolutely not. When a BSD camp developer uses the BSD license this is precisely what they give up, and more. Their code can be used in proprietary software in fact. BSD camp developers cannot complain that their code is being used in ways they don't approve of.
Similarly when BSD developers complain that they can't use GPL code for the reasons above they are being disingenuous. By its very nature the BSD license admits the existence of other ways of distributing software, so they should not complain that it does happen in practice.
It would be much more productive to everybody if the BSD developers expressed happiness about seeing their code used in GPLed products (as well as in proprietary ones), and continue to advocate the BSD license as a license that actually encourages even proprietary developers to do the same thing in practice in practical examples, not just theoretical ones.
Like I said earlier, even Microsoft is starting to release code under BSD-like licenses. I think this might be indication that the BSD camp is doing something right. Is Microsoft doing that of its own volition or because of the widespread percieved threat of GPL software I honestly don't know. This is a question for another day.
In the meantime peace in the F/OSS camps would be absolutely terrific.
There are still quite a few left
d
Cat
Ocelot
Bobcat
Lynx
Puma
Cougar
Leopar
Lion
That ought to do for a few more years.