"It's not more dangerous than the output of other industrial sites"
Umm, really?
Let's take just one example out of the so many possible. Look at one of the more 'benign' risks of nuclear power: tritium releases into ground water: How many industries other than nuclear plants need federal "Lessons-Learned Task Task Forces" for stuff like that?...
Tritium releases such as this one in august 2006 in California:
Cancer-causing tritium is found under the nuclear plant. Drinking water supplies are tested.
Radioactive, cancer-causing tritium has leaked into the groundwater beneath the San Onofre nuclear power plant, prompting the closure of one drinking-water well in southern Orange County, authorities said.
"simply because my best guess was that I am the only person who will ever want feature x"
You may have been underestimating 'the others'... "Release early, release often" means release it, even if you think it's (still) useless junk. Just label it as that, and perhaps others will find it better than useless junk, or if needed maybe clean it up and turn it into something you never even thought it could be.
At least send a message 'listen guys, this is what I threw together for myself and here is why', or put up a webpage on a blog or wiki somewhere with your patches and mention the site once on the mailing list.
Do it for the others, whom may surprise you.
A lot of programmers with good intentions end up never releasing what they've made, and what could have turned into something great, just because they want to 'clean it up first', or because they think 'nobody would want it' (they wanted it, so somebody did, making it less than unlikely that somebody else wants it too). Release it, just be honest and say that even you the creator thinks it's dirty and useless. Perhaps others disagree about the 'useless', or are better/faster than you in cleaning it up, or maybe it inspires others to make something similar, or more advanced, in 'the right way'.
"Mike wonders why the kernel tries so hard, rather than just failing allocation requests when memory gets too tight."
I realize this is formulated in a negative way, with no prior reservation of resources, but erm, it was fast and easy right now and gave a sufficient response to the thread with the lowest possible latency, and if and when it ever becomes important I'll reformulate it nicely right before it's needed, and until that time those resources stay available for other uses. So be warned, here it comes: Probably that is because Mike doesn't know what lazy allocation means, why it is used, and that that means that there is not an allocation request to fail when the OOM condition happens?
Hmm, I sound so arrogant in this post that I'm probably wrong... But I can't help but feel that I'm pretty close to being right...
"If it's not superscalar, why does it need a branch predictor?"
Because it has a pipeline and without a predictor a branch means a pipeline stall until the branch comes out the execution stage. With a predictor, even a simple one, it means a pipeline flush only when the predictor is wrong, which means you can gain a lot of cycles with even a very simple predictor.
"One problem that many forget looking back on the "good old days" of sound is that you couldn't get sound from more than one thing."
And that's fine for me, when I'm playing a video, the email program or battery monitor doesn't have to bling at me.
And that's fine for me, because with pulseaudio I often can't get sound from less than one thing (no sound at all untill I killall pulseaudio). Now that's annoying.
To be ever successful, pulseaudio should be able to run just fine without realtime privileges on a kernel that doesn't have 1000hz timer (etc).
It's fine if it will run better with those features, but it should not run any worse than a system without pulseaudio without them.
For example: If I have a real reason to want a program to have low latency, and run it with realtime privileges, I would not want pulseaudio to sit in its way and have it share real-time priority.
Without pulseaudio I would not have that problem, so it's pulseaudio that is the problem.
Right, good to see I'm not the only one that has found that pulseaudio (and arts and esound before that) creates more problems than it fixes, today.
Maybe those future features are cool, but I have not seen them work yet, and I don't want those features more than the headaches that pulseaudio gives today.
Compare video and 'compositing', and '3d effects'. Luckily, that works well for me now, but it didn't in the past, and still doesn't work (completely) for many people. When compositing or 3d effects don't work for your system, then either is has already been switched off automatically, or you can switch it off easily in the system settings (and even with a special three-finger salute (alt-shift-f12)), and you system will work as if compositing and 3d effect never existed. It never breaks video on your system.
That's the successful way of making such an invasive, and initially often broken, improvement in a service. Nobody got angry at compositing and 3d effects, except when they wanted it and couldn't use it because it didnt' work (well) on their system, but at least then their systems worked fine without it, they just didn't get the features it gave.
Some of the people who where experiencing problems with those feature were able to test with it and report problems/bugs in detail to the developers, and still be able use their systems in daily use after disabling the features, providing useful feedback to the developers, instead of providing hordes of angry, unhelpful, users that the developers needed to 'defend' themselves from.
That's how pulseaudio should be.
Pulseaudio today has no place in a distribution other than an optional addon for people who want it, or at the very least, it must be possible to completely and utterly disable it with a simple, easy to find, single checkbox in the sound configuration menu of the system settings program. In ubuntu, it is installed by default and is listed as required in the dependencies and build-deps of too many packages, which it shouldn't, because 'it breaks stuff'. And after you have it, it's a major pain to try to disable or uninstall.
I find that my audio works fine without pulseaudio, so why would I have to use a still buggy program under development that is messing around with my audio, using up memory, using CPU, adding latency, causing audio to be choppy sometimes, and most of all, making applications that try to use audio be silent or sometimes even hang. What is up with kde that every time I click on a pulldown menu, that it needs to call a pulseaudio function? (replace/usr/bin/pulseaudio with a script that does 'sleep 5' and killall pulseaudio, and you'll see what I mean). Where else is there pulseaudio overhead that makes the desktop programs less responsive?
Perhaps pulseaudio itself is still buggy, but then it shouldn't be enabled by default and in so mamy package's required 'build dependencies', it should only be enabled for people who specifically choose it, and when building a package, it should not be listed in the build-deps.
Pehaps it can't be fixed without first changing thing elsewhere (kernel, sound drivers?), but then it's the same conclusion; It's still not ready for prime time. Fix what needs to be fixed first.
Perhaps it can't be fixed ever, then it should be removed.
And the detail in this case is that this specially tweaked "MPG" rating is not MPG of gasoline consumed, but includes some kind of 'electricity to gasoline' conversion calculation for the "G", so a more accurate term is probably "MPG PMPO"
V2 is a piece of tape with a hole in it so that it sees one blob. If needed V3 will be a short paper tube.
The system will fail to count correctly often anyway. For example, where the cablebox is inside a case with a door that can close or diffuses the light (which is already the case in many home setups). Or for example, it will count the dog laying in front of the tv, or sitting on the couch... and/or not see people sitting in the 2nd row of the enthousiast home theater setup... etc etc... If the count is unreliable, the data is useless...
But... theorizing some more, a shaped sheet of metal can create such a beam that can be received at likely close to 100% efficiency, for free, using sunlight as input, and given that such an elevator will likely be far from densely populated area's, there should be plenty of cheap enough space to put a large enough reflector (think sun reflector plant). No need for a fancy high-tech laser, no need to generate megawatts of light from some other energy source, as long as they can make the light from a field of mirrors focus well enough to go to a solar panel on the receiving end (and not go to the device on the cable...)
While sunlight isn't easy to focus, there is a _lot_ of energy in sunlight (when there are no clouds), and it's already available every day during daytime (caveat clouds).
While easy to 'focus', I would not be surprised if lasers will always suck for transmitting power, because they are extremely narrow-band. But I'm no expert in the field, at all...
Of course clouds would ruin such a plan, but so would it for lasers...
2%? Solar cells get up to 42% (20% thin film) and that is receiving 'beamed' power from far away... There must be a way to apply that technology there and get a much better number than 2%...
Hmm, interesting idea, a microcell that allows only emergency calls (none of the other calls go through). A law or contract with the providers may be needed to ensure the microcell has the correct id's to make all phones automatically roam on it.
Not jamming, but stopping abuse by students by disalowing all calls except to 911 (or the school nurse etc)...
Just like the microcells on cruise ships, the schools actually could use it as a revenue stream: open up calls and texting during breaks, but for a roaming (aka crazy high) price... Not sure if I would like that as a parent though... or my kid will have to use a prepaid;-)
Why do so many people think that "void * a = b->c" dereferences b? It takes the address of c in b and assigns it to a. It's only doing a pointer calculation: assigning an address of something to a pointer, it's not accessing any memory, so there is no way for a page fault or 'blow up' of any kind to occur.
It dereferencing the null pointer would 'blow up', then the exploit would not have worked because no code after the 'tun->sk' would be executed.
The check is not placed wrong, it should be safe as long as *sk isn't used before the check. The *sk assignment does not dereference to a memory location, it does nothing more than adding an offset to the other pointer: ((int)sk - (int)tun) is the offset of sk in 'struct sock'.
The compiler is wrong in assuming tun is always non-NULL at that point in the code.
It's certainly a compiler bug, it's the same as optimizing the 'if (!tun)' out of this code:
const int sk_off = 123; int func(int tun) {
int sk = tun + sk_off;
Both linux vservers and bsd jails have existed for plenty of years before vmware, xen, virtualbox, etc.
And, on that subject, this http://en.wikipedia.org/wiki/LinuxPMI is based on 'mosix', which made your cluster of linux boxes appear as one single massive machine, with transparent process migration and all that.
There are lots of virtualization and clustering options out there.
"C (and even assembly) can't realize that the same inputs to a routine always cause the same output, and therefore cache the return value and just return it"
And, C compilers have performed such optimization automatically on a much finer scale than functions for ages (common subexpression elimination), and there really is no reason why future versions won't do it just as much, and on all the same scales as java compilers/vm's eventually will.
"The real issue is, when Java 7, 8 or 9 comes out, ALL java code ever produced will run faster without touching the compiled system."
Sure, a future version will beat something that exists today, future versions of java vm's will be faster than current versions (thank $DEITY)... But so will C compilers... C compilers beat java vm's today, and there is nothing about the java language that can't be done with C, see for example http://llvm.org/
Quite possibly the future of executables (for certain types of executables) is more towards the VM/jit approach, but that is language independent.
While many languages are much easier to use than C (in their application areas), saving development time, and can be for all intents and purposes as fast as it needs to be, saying they will be faster than C will be, is falsely assuming that C compilers have stopped developing further... Perhaps faster than C is today, but not faster than it will be.
imho, the bucket of gold at the end of the rainbow is there where you can choose your programming language freely, interface across language barriers with ease, and build a final program from such a mixture of languages if needed.
Slashdot Mirror
"It's not more dangerous than the output of other industrial sites"
Umm, really?
Let's take just one example out of the so many possible. Look at one of the more 'benign' risks of nuclear power: tritium releases into ground water: How many industries other than nuclear plants need federal "Lessons-Learned Task Task Forces" for stuff like that?...
Tritium releases such as this one in august 2006 in California:
http://articles.latimes.com/2006/aug/18/local/me-radioactive18
Groundwater Reveals Radiation Leak at San Onofre
Cancer-causing tritium is found under the nuclear plant. Drinking water supplies are tested.
Radioactive, cancer-causing tritium has leaked into the groundwater beneath the San Onofre nuclear power plant, prompting the closure of one drinking-water well in southern Orange County, authorities said.
"simply because my best guess was that I am the only person who will ever want feature x"
You may have been underestimating 'the others'... "Release early, release often" means release it, even if you think it's (still) useless junk. Just label it as that, and perhaps others will find it better than useless junk, or if needed maybe clean it up and turn it into something you never even thought it could be.
At least send a message 'listen guys, this is what I threw together for myself and here is why', or put up a webpage on a blog or wiki somewhere with your patches and mention the site once on the mailing list.
Do it for the others, whom may surprise you.
A lot of programmers with good intentions end up never releasing what they've made, and what could have turned into something great, just because they want to 'clean it up first', or because they think 'nobody would want it' (they wanted it, so somebody did, making it less than unlikely that somebody else wants it too). Release it, just be honest and say that even you the creator thinks it's dirty and useless. Perhaps others disagree about the 'useless', or are better/faster than you in cleaning it up, or maybe it inspires others to make something similar, or more advanced, in 'the right way'.
"Mike wonders why the kernel tries so hard, rather than just failing allocation requests when memory gets too tight."
I realize this is formulated in a negative way, with no prior reservation of resources, but erm, it was fast and easy right now and gave a sufficient response to the thread with the lowest possible latency, and if and when it ever becomes important I'll reformulate it nicely right before it's needed, and until that time those resources stay available for other uses. So be warned, here it comes: Probably that is because Mike doesn't know what lazy allocation means, why it is used, and that that means that there is not an allocation request to fail when the OOM condition happens?
Hmm, I sound so arrogant in this post that I'm probably wrong... But I can't help but feel that I'm pretty close to being right...
"If it's not superscalar, why does it need a branch predictor?"
Because it has a pipeline and without a predictor a branch means a pipeline stall until the branch comes out the execution stage. With a predictor, even a simple one, it means a pipeline flush only when the predictor is wrong, which means you can gain a lot of cycles with even a very simple predictor.
And slow down interactive response such as seeking?
No, latency is _not_ good.
"One problem that many forget looking back on the "good old days" of sound is that you couldn't get sound from more than one thing."
And that's fine for me, when I'm playing a video, the email program or battery monitor doesn't have to bling at me.
And that's fine for me, because with pulseaudio I often can't get sound from less than one thing (no sound at all untill I killall pulseaudio). Now that's annoying.
To be ever successful, pulseaudio should be able to run just fine without realtime privileges on a kernel that doesn't have 1000hz timer (etc).
It's fine if it will run better with those features, but it should not run any worse than a system without pulseaudio without them.
For example: If I have a real reason to want a program to have low latency, and run it with realtime privileges, I would not want pulseaudio to sit in its way and have it share real-time priority.
Without pulseaudio I would not have that problem, so it's pulseaudio that is the problem.
Right, good to see I'm not the only one that has found that pulseaudio (and arts and esound before that) creates more problems than it fixes, today.
Maybe those future features are cool, but I have not seen them work yet, and I don't want those features more than the headaches that pulseaudio gives today.
Compare video and 'compositing', and '3d effects'. Luckily, that works well for me now, but it didn't in the past, and still doesn't work (completely) for many people. When compositing or 3d effects don't work for your system, then either is has already been switched off automatically, or you can switch it off easily in the system settings (and even with a special three-finger salute (alt-shift-f12)), and you system will work as if compositing and 3d effect never existed. It never breaks video on your system.
That's the successful way of making such an invasive, and initially often broken, improvement in a service. Nobody got angry at compositing and 3d effects, except when they wanted it and couldn't use it because it didnt' work (well) on their system, but at least then their systems worked fine without it, they just didn't get the features it gave.
Some of the people who where experiencing problems with those feature were able to test with it and report problems/bugs in detail to the developers, and still be able use their systems in daily use after disabling the features, providing useful feedback to the developers, instead of providing hordes of angry, unhelpful, users that the developers needed to 'defend' themselves from.
That's how pulseaudio should be.
Pulseaudio today has no place in a distribution other than an optional addon for people who want it, or at the very least, it must be possible to completely and utterly disable it with a simple, easy to find, single checkbox in the sound configuration menu of the system settings program. In ubuntu, it is installed by default and is listed as required in the dependencies and build-deps of too many packages, which it shouldn't, because 'it breaks stuff'. And after you have it, it's a major pain to try to disable or uninstall.
I find that my audio works fine without pulseaudio, so why would I have to use a still buggy program under development that is messing around with my audio, using up memory, using CPU, adding latency, causing audio to be choppy sometimes, and most of all, making applications that try to use audio be silent or sometimes even hang. What is up with kde that every time I click on a pulldown menu, that it needs to call a pulseaudio function? (replace /usr/bin/pulseaudio with a script that does 'sleep 5' and killall pulseaudio, and you'll see what I mean). Where else is there pulseaudio overhead that makes the desktop programs less responsive?
Perhaps pulseaudio itself is still buggy, but then it shouldn't be enabled by default and in so mamy package's required 'build dependencies', it should only be enabled for people who specifically choose it, and when building a package, it should not be listed in the build-deps.
Pehaps it can't be fixed without first changing thing elsewhere (kernel, sound drivers?), but then it's the same conclusion; It's still not ready for prime time. Fix what needs to be fixed first.
Perhaps it can't be fixed ever, then it should be removed.
And the detail in this case is that this specially tweaked "MPG" rating is not MPG of gasoline consumed, but includes some kind of 'electricity to gasoline' conversion calculation for the "G", so a more accurate term is probably "MPG PMPO"
V2 is a piece of tape with a hole in it so that it sees one blob. If needed V3 will be a short paper tube.
The system will fail to count correctly often anyway. For example, where the cablebox is inside a case with a door that can close or diffuses the light (which is already the case in many home setups). Or for example, it will count the dog laying in front of the tv, or sitting on the couch... and/or not see people sitting in the 2nd row of the enthousiast home theater setup... etc etc... If the count is unreliable, the data is useless...
Do you seriously believe that modern concrete is the same recipe, strength, and longevity as roman concrete?
But... theorizing some more, a shaped sheet of metal can create such a beam that can be received at likely close to 100% efficiency, for free, using sunlight as input, and given that such an elevator will likely be far from densely populated area's, there should be plenty of cheap enough space to put a large enough reflector (think sun reflector plant). No need for a fancy high-tech laser, no need to generate megawatts of light from some other energy source, as long as they can make the light from a field of mirrors focus well enough to go to a solar panel on the receiving end (and not go to the device on the cable...)
While sunlight isn't easy to focus, there is a _lot_ of energy in sunlight (when there are no clouds), and it's already available every day during daytime (caveat clouds).
While easy to 'focus', I would not be surprised if lasers will always suck for transmitting power, because they are extremely narrow-band. But I'm no expert in the field, at all...
Of course clouds would ruin such a plan, but so would it for lasers...
2%? Solar cells get up to 42% (20% thin film) and that is receiving 'beamed' power from far away... There must be a way to apply that technology there and get a much better number than 2%...
Hmm, interesting idea, a microcell that allows only emergency calls (none of the other calls go through). A law or contract with the providers may be needed to ensure the microcell has the correct id's to make all phones automatically roam on it.
Not jamming, but stopping abuse by students by disalowing all calls except to 911 (or the school nurse etc)...
Just like the microcells on cruise ships, the schools actually could use it as a revenue stream: open up calls and texting during breaks, but for a roaming (aka crazy high) price... Not sure if I would like that as a parent though... or my kid will have to use a prepaid ;-)
but, erm...
You're right...
I should have had that coffee first...
In fact, it already was fixed at least days before this /. article about it...
"any pointer that was dereferenced can't be NULL"
It's not being dereferenced.
Why do so many people think that "void * a = b->c" dereferences b? It takes the address of c in b and assigns it to a. It's only doing a pointer calculation: assigning an address of something to a pointer, it's not accessing any memory, so there is no way for a page fault or 'blow up' of any kind to occur.
It dereferencing the null pointer would 'blow up', then the exploit would not have worked because no code after the 'tun->sk' would be executed.
No it's assigning the address of the sk member in the struct to the sk pointer local variable...
The check is not placed wrong, it should be safe as long as *sk isn't used before the check. The *sk assignment does not dereference to a memory location, it does nothing more than adding an offset to the other pointer: ((int)sk - (int)tun) is the offset of sk in 'struct sock'.
The compiler is wrong in assuming tun is always non-NULL at that point in the code.
It's certainly a compiler bug, it's the same as optimizing the 'if (!tun)' out of this code:
const int sk_off = 123;
int func(int tun)
{
int sk = tun + sk_off;
if (!tun) return -1;
return sk;
}
Oh, and not all flash is an ssd either... (e.g. the BIOS chip)
So, actually: SSD != Flash...
Flash is an SSD, but not every SSD is flash...
"Automated Clearing House".... Everytime I see that, I hear 'You May Already Have Won'...
Did the person who came up with that name think banking was like sweepstakes???
Linux has that with: http://linux-vserver.org/
Both linux vservers and bsd jails have existed for plenty of years before vmware, xen, virtualbox, etc.
And, on that subject, this http://en.wikipedia.org/wiki/LinuxPMI is based on 'mosix', which made your cluster of linux boxes appear as one single massive machine, with transparent process migration and all that.
There are lots of virtualization and clustering options out there.
"C (and even assembly) can't realize that the same inputs to a routine always cause the same output, and therefore cache the return value and just return it"
The 'const' function attribute does that and works fine: http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html
And, C compilers have performed such optimization automatically on a much finer scale than functions for ages (common subexpression elimination), and there really is no reason why future versions won't do it just as much, and on all the same scales as java compilers/vm's eventually will.
"The real issue is, when Java 7, 8 or 9 comes out, ALL java code ever produced will run faster without touching the compiled system."
Sure, a future version will beat something that exists today, future versions of java vm's will be faster than current versions (thank $DEITY)... But so will C compilers... C compilers beat java vm's today, and there is nothing about the java language that can't be done with C, see for example http://llvm.org/
Quite possibly the future of executables (for certain types of executables) is more towards the VM/jit approach, but that is language independent.
While many languages are much easier to use than C (in their application areas), saving development time, and can be for all intents and purposes as fast as it needs to be, saying they will be faster than C will be, is falsely assuming that C compilers have stopped developing further... Perhaps faster than C is today, but not faster than it will be.
imho, the bucket of gold at the end of the rainbow is there where you can choose your programming language freely, interface across language barriers with ease, and build a final program from such a mixture of languages if needed.