I am not sure what you mean, but the heartbleed bug was in the initial version of the heart beat feature. Maybe you are thinking of the Debian OpenSSL PRNG bug? This bug was introduced when shutting up valgrind warning not to improve performance though.
I like how your arguments over the years get more and more detached from reality because at the end you will always try to come to the desired conclusion that we need nuclear despite the world moving in an entirely different direction. It will be great fun to watch this become even more absurd in the next years;-)
The fact that EVs are charged in the night is mostly due to the fact that electricity is cheap and not otherwise needed in the night and that this is still the most convenient way as long as there is no charging infrastructure at work places. This is despite the fact hat solar is of course available during the day. Of course, most cars are moved only for a fraction of the time even during the day and in principle it makes a lot of sense to charge EVs also at the day should this be necessary in the future. EVs include their own storage and your argument that we would need additional grid storage to move energy to the night to put them into the storage of the EVs so that it can then be consumed during the day is not very strong. A lot of people will just also charge at day, e.g. at work places if this is happens to be cheaper. This means that the batteries in the EVs and grid storage will not compete in the long run, instead EVs will be charged whenever this makes most sense to balance grid because then electricity will be cheapest. Also the joint market for storage from EV and grid will make storage cheaper and not more expensive as you imply.
They can reduce max stack size in come cases. E.g. if you split one array into two smaller arrays but you don't know how big the smaller arrays are. In any case, they never increase stack size when compared to static arrays on the stack.
So you're aware that GNU introduced features often way in advance of any standard and that the GNU syntax/semantics don't always match the ISO version.
Yes of course. In fact, I added myself a GNU extension. I am also participating in WG14.
Let's see what ISO says about VLAs:
C99 adds a new array type called a variable length array type. The inability to declare arrays whose size is known only at execution time was often cited as a primary deterrent to using C as a numerical computing language. Adoption of some standard notion of execution time arrays was considered crucial for C’s acceptance in the numerical computing world.
Does this match your experience?
Absolutely. I use C for numerical computing and VLAs a very important.
Would discontiguous pools of contiguous memory, giving you the ability to make anything flexible size, be that much worse as that's what the compiler will be using anyway?
I don't understand what you are trying to say. The VLA will live on the stack or the heap depending on where one allocates it. In both cases, there is no way to resize it. Making it resizable is much harder and no compiler does this as it would require a level of indirection which reduces performance and would require some kind of automatic memory management (automatically running destructors). Of course, you can always add your own abstraction for resizable arrays.
VLA are part of the standard and it is a myth that removing them it helps security as it removes price information about run-time bounds from the compiler's view. In my opinion not using VLA is a major step back for security. (Yes, I contributed to with this overall effort myself, but only where it were fake VLAs which really had a constant size but the compiler couldn't know this).
For GNUisms in general, we will certainly try to standardize some of them (those which are useful, well-defined, and supported by other compilers).
Huh? There is nothing unsafe with VLA. They also tend to *reduce* stack usage, as the alternative are oversized fixed size arrays on the stack. If you care about the dynamic sized stack, then you also can't have functions calls in a conditional path.
The other problem is that doesn't solve any real problem but takes a away features. A lot of people where misled to believe that here a huge performance gains or other advantages to be gained from switching away from X. But those are mostly based on myths on how about X works (e.g. the idea that extensions unused by modern apps somehow constrain them). Of course, Wayland just reimplements a small subset of X in a very similar way, so performance is essentially the same.
This is extremely useful to me. You can, log into a remote computer to use special software, or attached hardware, etc.. You can sit next to an arbitrary colleague and log into your computer showing some stuff or use the computer in the conference room to log into your computer running which runs some simulation and demonstrate live it in a presentation. It is just sad it is not supported more with moving windows or reconnecting which are both supported by X in the underlying protocol (I know I implemented proof-of-principle apps which do this, so please don't argue this would be impossible with X).
I disagree. X is a beautifully engineered protocol which powerful, elegant, and extendable. Throwing it away and breaking compatibility with this ecosystem is the worst blunder Linux distributions could do. Also the security problem reported here is unrelated to the protocol,
Yes, modern apps use X in different way, but they are in now way limited by old extensions. People claiming that old unused extensions like server-side fonts constrain anything clearly do know how X work. If you think otherwise, please explain exactly how you think this could be the case.
Well, I am a physicist and I follow energy policy closely and especially the energy transition in Germany. In the first article you there is so much wrong, it would take quite some time to take it apart. But a couple of comments: It is not a secret how the German electricity price is composed and neither is where the price increase comes from. The article makes it sound like a mystery and then blames it on an effect which isn't really that important at the moment. A large part of the increase of the electricity price actually comes from the feed-in tariff for renewables (and because we know this from actual numbers it is also clear that the explanation put forward of the article is not the reason). It is not surprising that if you support the development of renewables using a feed-in tariff and then this is successful and the share of renewables increases then also the corresponding fees increase and the overall power price. Now, other technologies like nuclear also got a huge amount of subsidies for development but those were paid from general taxes so did not affect the price. So only discussing the electricity price is misleading from the onset. Now using a feed-in tariff for renewables instead of general taxes was entirely intentional: The idea was to increase the price to also encourage saving (and electricity consumption is in fact on a slight downward trend in Germany). Now, there are couple of other important things to unerstand: Although the increase in price is largely due to the fee it is still a relatively small part of the overall cost, there are other taxes and fees which make electricity expensive in Germany and which are mostly unrelated to renewables (e.g. Germany maintains one of the most reliable grids). Second, the feed-in tariff was very successful: In created a huge market for wind and solar that then caused a huge drop in prices so that the fees are expected to again decrease in the future. In contrast, nuclear never got cheaper so the huge amount of tax-payer money spend for development did not nearly achieve similar effects.
Germany is spending a ton of money, but they aren't getting results.
I think this is misrepresenting the situation quite a bit. Germany is spending a ton of money and increased the share of renewables for generation of electricity from less than 5% to more than 33% in the last twenty years. This also helped bring down the cost to renewables substantially. This is a "result". You dismiss this result because Germany did not bring down CO2 emissions as much (there are down but not by much). The reason is that Germany decided to shut down nuclear first instead of coal. If you say this is mistake, I agree, but this is what Germans wanted. So saying there is no "result" is highly misleading. Also it is very obvious that renewables will start to reduce CO2 emissions of Germany in the future once renewables eat into coal and lignite. And this has already started.
Also, despite shutting down some nuclear, Germany still compares well to Canada, Australia, Russia, Japan, South Korea, and some other industrialized countries - not just Trumpistan.
While lawsuits and bureaucracy certainly contributed to that, it is by no means the only factor. I would say it also has a lot to do with the size and the complexity of the projects. It is like huge software projects almost always have cost overruns. Surely, standardized software design methodology would prevent this too, right? In practice it is never easy and the same is true for nuclear. On paper, it all looks good and simple, but it practice it quickly gets really complicated.
Not really, Some electricity exported from France may flow through Germany. But Germany is actually a net exporter of electricity all year round. Yes, France has to import in the winter and also sometimes in summer if it gets so hot hat the nuclear plants have to be down regulated to avoid over heating of rivers. Also sometimes a lot of plants are down for some reason.
You are comparing a price from 2014 for a plant which opened now to a plant opening (maybe) in 2025 or so. Guaranteed prices for new contracts for offshort wind are 60 £/MWh as of last year.
Nuclear has gotten subsidies for more than 60 years.It always ever got more expensive. There is a word for doing the same thing over and over again and expecting a different result.
If that works for other low CO2 energy sources then it should apply to nuclear as well.
No. Why?
Nuclear power also works at night, in high winds, in no winds, when it's raining, cold, hot... okay maybe it has to reduce power when it gets really hot.
Great. But the problem is that you basically always have to have it running to not make the economics worse.... This means it is not too useful to have nuclear in a modern grid.
That's why we need a mix.
Yes, but a mix without nuclear as nuclear is simply too expensive.
Pick energy that's cheap, low CO2, and safe. The top three on that is onshore wind, hydro, and nuclear, not necessarily in that order.
No nuclear is not cheap. You said yourself we should just subsidize it until its cheap. So you are even contradicting yourself. If it were actually cheap, people would roll out nuclear and there would be no nuclear fanboys whining on slashdot on how we should have nuclear.
Solar PV is just a bad idea all around.
No, it is a great idea to give it a chance as it is getting cheaper and cheaper. In contrast to nuclear which always got more expensive in the past.
If nuclear power costs too much then lower the price. It's that simple.
If it were simple. Nuclear would be cheap by now. It is a very old technology which still isn't cheap. I think this makes it very obvious that it is not simply.
I know nobody reads the story... But this is an old contract for a project going for a project opening now. Hinkley will open in 2025 or so...
"Walney Extension was among the first renewable projects to secure a so-called contract for difference (CFD) subsidy from the British government in 2014. The contract guarantees it a minimum price for electricity of 150 pounds ($195) per megawatt hour (MWh) for 15 years. Since this was awarded, the cost of offshore wind has fallen dramatically to a low of 57.50 pounds per MWh in the last auction held in 2017."
All the undefined behavior in C can be used for a compiler to optimize the code and then fail horribly if the undefined behavior is triggered at run-time. Alternatively, compilers could just insert runtime checks. To some degree this can be done with the undefined-behavior sanitizer. So a language with a lot of undefined behavior such as C can be both: relatively safe or fast depending on the compiler options. In the past, the later option has been neglected by compiler writers but this is changing.
There are some deficiencies in C which I think can be fixed by adding a couple of minor features (e.g. certain attributes which can provide information for static analysis). The biggest problem in my opinion is that the standard library is so small, so programmers often write there own open-coded alternatives which then tend to be buddy and unsafe instead where other languages offer well-defined APIs and carefully implemented algorithms.
There is only a problem if you think everything published in science must be true. This isn't the case and never was. There was a time, there was no peer review. And also otherwise good journals sometimes publish bad papers. So the solution for scientists is obvious: Do not believe everything you read. If a bad journal published only bad science, nobody will bother to read it and people who publish there do not gain reputation. So there is not really a problem for science... It is a problem though for stupid journalists who think every published article must be true or for stupid committees who judge applicants by the number of publications in peer-reviewed journals. If "fake" journals help getting rid of this stupidity, this can only be a good thing.
Having said this, there are definitely problem in science we need to address: And even the high-ranking journals often have standards which are too low in terms of weak statistics, clear descriptions, openness of data and code, etc.
Slashdot Mirror
I am not sure what you mean, but the heartbleed bug was in the initial version of the heart beat feature. Maybe you are thinking of the Debian OpenSSL PRNG bug? This bug was introduced when shutting up valgrind warning not to improve performance though.
I like how your arguments over the years get more and more detached from reality because at the end you will always try to come to the desired conclusion that we need nuclear despite the world moving in an entirely different direction. It will be great fun to watch this become even more absurd in the next years ;-)
The fact that EVs are charged in the night is mostly due to the fact that electricity is cheap and not otherwise needed in the night and that this is still the most convenient way as long as there is no charging infrastructure at work places. This is despite the fact hat solar is of course available during the day. Of course, most cars are moved only for a fraction of the time even during the day and in principle it makes a lot of sense to charge EVs also at the day should this be necessary in the future. EVs include their own storage and your argument that we would need additional grid storage to move energy to the night to put them into the storage of the EVs so that it can then be consumed during the day is not very strong. A lot of people will just also charge at day, e.g. at work places if this is happens to be cheaper. This means that the batteries in the EVs and grid storage will not compete in the long run, instead EVs will be charged whenever this makes most sense to balance grid because then electricity will be cheapest. Also the joint market for storage from EV and grid will make storage cheaper and not more expensive as you imply.
Yeah, right... Daniel Stone of Wayland is the only one understanding X.
If you don't want to allocate on the stack you can also not call a function as the stack frame is allocated on the stack...
They can reduce max stack size in come cases. E.g. if you split one array into two smaller arrays but you don't know how big the smaller arrays are. In any case, they never increase stack size when compared to static arrays on the stack.
So you're aware that GNU introduced features often way in advance of any standard and that the GNU syntax/semantics don't always match the ISO version.
Yes of course. In fact, I added myself a GNU extension. I am also participating in WG14.
Let's see what ISO says about VLAs:
C99 adds a new array type called a variable length array type. The inability to declare arrays whose size is known only at execution time was often cited as a primary deterrent to using C as a numerical computing language. Adoption of some standard notion of execution time arrays was considered crucial for C’s acceptance in the numerical computing world.
Does this match your experience?
Absolutely. I use C for numerical computing and VLAs a very important.
Would discontiguous pools of contiguous memory, giving you the ability to make anything flexible size, be that much worse as that's what the compiler will be using anyway?
I don't understand what you are trying to say. The VLA will live on the stack or the heap depending on where one allocates it. In both cases, there is no way to resize it. Making it resizable is much harder and no compiler does this as it would require a level of indirection which reduces performance and would require some kind of automatic memory management (automatically running destructors). Of course, you can always add your own abstraction for resizable arrays.
VLA are part of the standard and it is a myth that removing them it helps security as it removes price information about run-time bounds from the compiler's view. In my opinion not using VLA is a major step back for security. (Yes, I contributed to with this overall effort myself, but only where it were fake VLAs which really had a constant size but the compiler couldn't know this).
For GNUisms in general, we will certainly try to standardize some of them (those which are useful, well-defined, and supported by other compilers).
Huh? There is nothing unsafe with VLA. They also tend to *reduce* stack usage, as the alternative are oversized fixed size arrays on the stack. If you care about the dynamic sized stack, then you also can't have functions calls in a conditional path.
The other problem is that doesn't solve any real problem but takes a away features. A lot of people where misled to believe that here a huge performance gains or other advantages to be gained from switching away from X. But those are mostly based on myths on how about X works (e.g. the idea that extensions unused by modern apps somehow constrain them). Of course, Wayland just reimplements a small subset of X in a very similar way, so performance is essentially the same.
This is extremely useful to me. You can, log into a remote computer to use special software, or attached hardware, etc.. You can sit next to an arbitrary colleague and log into your computer showing some stuff or use the computer in the conference room to log into your computer running which runs some simulation and demonstrate live it in a presentation. It is just sad it is not supported more with moving windows or reconnecting which are both supported by X in the underlying protocol (I know I implemented proof-of-principle apps which do this, so please don't argue this would be impossible with X).
I disagree. X is a beautifully engineered protocol which powerful, elegant, and extendable. Throwing it away and breaking compatibility with this ecosystem is the worst blunder Linux distributions could do. Also the security problem reported here is unrelated to the protocol,
Yes, modern apps use X in different way, but they are in now way limited by old extensions. People claiming that old unused extensions like server-side fonts constrain anything clearly do know how X work. If you think otherwise, please explain exactly how you think this could be the case.
Well, I am a physicist and I follow energy policy closely and especially the energy transition in Germany. In the first article you there is so much wrong, it would take quite some time to take it apart. But a couple of comments: It is not a secret how the German electricity price is composed and neither is where the price increase comes from. The article makes it sound like a mystery and then blames it on an effect which isn't really that important at the moment. A large part of the increase of the electricity price actually comes from the feed-in tariff for renewables (and because we know this from actual numbers it is also clear that the explanation put forward of the article is not the reason). It is not surprising that if you support the development of renewables using a feed-in tariff and then this is successful and the share of renewables increases then also the corresponding fees increase and the overall power price. Now, other technologies like nuclear also got a huge amount of subsidies for development but those were paid from general taxes so did not affect the price. So only discussing the electricity price is misleading from the onset. Now using a feed-in tariff for renewables instead of general taxes was entirely intentional: The idea was to increase the price to also encourage saving (and electricity consumption is in fact on a slight downward trend in Germany). Now, there are couple of other important things to unerstand: Although the increase in price is largely due to the fee it is still a relatively small part of the overall cost, there are other taxes and fees which make electricity expensive in Germany and which are mostly unrelated to renewables (e.g. Germany maintains one of the most reliable grids). Second, the feed-in tariff was very successful: In created a huge market for wind and solar that then caused a huge drop in prices so that the fees are expected to again decrease in the future. In contrast, nuclear never got cheaper so the huge amount of tax-payer money spend for development did not nearly achieve similar effects.
I corrected you many times. The official numbers can be found here: https://www.ag-energiebilanzen... [ag-energiebilanzen.de]
Power production in Germany in TWh 1990,1995,2000-2017 (German source, replace , with .)
lignite: 170,9 142,6 148,3 154,8 158,0 158,2 158,0 154,1 151,1 155,1 150,6 145,6 145,9 150,1 160,7 160,9 155,8 154,5 149,5 147,5
coal: 140,8 147,1 143,1 138,4 134,6 146,5 140,8 134,1 137,9 142,0 124,6 107,9 117,0 112,4 116,4 127,3 118,6 117,7 112,2 92,6
nuclear 152,5 154,1 169,6 171,3 164,8 165,1 167,1 163,0 167,4 140,5 148,8 134,9 140,6 108,0 99,5 97,3 97,1 91,8 84,6 76,3
gas 35,9 41,1 49,2 55,5 56,3 62,9 63,0 72,7 75,3 78,1 89,1 80,9 89,3 86,1 76,4 67,5 61,1 62,0 81,3 86,5
renewables 19,7 25,1 37,9 38,9 46,1 46,1 57,2 63,1 72,4 89,1 94,1 95,7 105,2 123,6 143,3 152,5 162,5 188,6 189,8 218,3
You know you are speading nonsense because I corrected you many times. The official numbers can be found here: https://www.ag-energiebilanzen...
Power production in Germany in TWh 1990,1995,2000-2017 (German source, replace , with .)
lignite: 170,9 142,6 148,3 154,8 158,0 158,2 158,0 154,1 151,1 155,1 150,6 145,6 145,9 150,1 160,7 160,9 155,8 154,5 149,5 147,5
coal: 140,8 147,1 143,1 138,4 134,6 146,5 140,8 134,1 137,9 142,0 124,6 107,9 117,0 112,4 116,4 127,3 118,6 117,7 112,2 92,6
nuclear 152,5 154,1 169,6 171,3 164,8 165,1 167,1 163,0 167,4 140,5 148,8 134,9 140,6 108,0 99,5 97,3 97,1 91,8 84,6 76,3
gas 35,9 41,1 49,2 55,5 56,3 62,9 63,0 72,7 75,3 78,1 89,1 80,9 89,3 86,1 76,4 67,5 61,1 62,0 81,3 86,5
renewables 19,7 25,1 37,9 38,9 46,1 46,1 57,2 63,1 72,4 89,1 94,1 95,7 105,2 123,6 143,3 152,5 162,5 188,6 189,8 218,3
So yes, nuclear has partially been replaced by renewables. Coals starts to be replaced and gas doesn't play the role you claim.
This wrong. Official numbers are here: https://www.ag-energiebilanzen...
Power production from coal and lignite in Germany 1990,1995,2000-2017 in TWh:
lignite: 170.9 142.6 148.3 154.8 158.0 158.2 158.0 154.1 151.1 155.1 150.6 145.6 145.9 150.1 160.7 160.9 155.8 154.5 149.5 147.5
coal: 140.8 147.1 143.1 138.4 134.6 146.5 140.8 134.1 137.9 142.0 124.6 107.9 117.0 112.4 116.4 127.3 118.6 117.7 112.2 92.6
Germany is spending a ton of money, but they aren't getting results.
I think this is misrepresenting the situation quite a bit. Germany is spending a ton of money and increased the share of renewables for generation of electricity from less than 5% to more than 33% in the last twenty years. This also helped bring down the cost to renewables substantially. This is a "result". You dismiss this result because Germany did not bring down CO2 emissions as much (there are down but not by much). The reason is that Germany decided to shut down nuclear first instead of coal. If you say this is mistake, I agree, but this is what Germans wanted. So saying there is no "result" is highly misleading. Also it is very obvious that renewables will start to reduce CO2 emissions of Germany in the future once renewables eat into coal and lignite. And this has already started.
Also, despite shutting down some nuclear, Germany still compares well to Canada, Australia, Russia, Japan, South Korea, and some other industrialized countries - not just Trumpistan.
While lawsuits and bureaucracy certainly contributed to that, it is by no means the only factor. I would say it also has a lot to do with the size and the complexity of the projects. It is like huge software projects almost always have cost overruns. Surely, standardized software design methodology would prevent this too, right? In practice it is never easy and the same is true for nuclear. On paper, it all looks good and simple, but it practice it quickly gets really complicated.
Not really, Some electricity exported from France may flow through Germany. But Germany is actually a net exporter of electricity all year round. Yes, France has to import in the winter and also sometimes in summer if it gets so hot hat the nuclear plants have to be down regulated to avoid over heating of rivers. Also sometimes a lot of plants are down for some reason.
You are comparing a price from 2014 for a plant which opened now to a plant opening (maybe) in 2025 or so. Guaranteed prices for new contracts for offshort wind are 60 £/MWh as of last year.
Nuclear is more expensive. It's that simple.
Then we should subsidize it until it's cheaper.
Nuclear has gotten subsidies for more than 60 years.It always ever got more expensive. There is a word for doing the same thing over and over again and expecting a different result.
If that works for other low CO2 energy sources then it should apply to nuclear as well.
No. Why?
Nuclear power also works at night, in high winds, in no winds, when it's raining, cold, hot... okay maybe it has to reduce power when it gets really hot.
Great. But the problem is that you basically always have to have it running to not make the economics worse.... This means it is not too useful to have nuclear in a modern grid.
That's why we need a mix.
Yes, but a mix without nuclear as nuclear is simply too expensive.
Pick energy that's cheap, low CO2, and safe. The top three on that is onshore wind, hydro, and nuclear, not necessarily in that order.
No nuclear is not cheap. You said yourself we should just subsidize it until its cheap. So you are even contradicting yourself. If it were actually cheap, people would roll out nuclear and there would be no nuclear fanboys whining on slashdot on how we should have nuclear.
Solar PV is just a bad idea all around.
No, it is a great idea to give it a chance as it is getting cheaper and cheaper. In contrast to nuclear which always got more expensive in the past.
If nuclear power costs too much then lower the price. It's that simple.
If it were simple. Nuclear would be cheap by now. It is a very old technology which still isn't cheap. I think this makes it very obvious that it is not simply.
I know nobody reads the story... But this is an old contract for a project going for a project opening now. Hinkley will open in 2025 or so...
"Walney Extension was among the first renewable projects to secure a so-called contract for difference (CFD) subsidy from the British government in 2014.
The contract guarantees it a minimum price for electricity of 150 pounds ($195) per megawatt hour (MWh) for 15 years.
Since this was awarded, the cost of offshore wind has fallen dramatically to a low of 57.50 pounds per MWh in the last auction held in 2017."
Thanks
What exactly are you talking about if you say "Verfied C"? I know of verified compiler such as CompCert.
I don't think there is a fundamental trade-off.
All the undefined behavior in C can be used for a compiler to optimize the code and then fail horribly if the undefined behavior is triggered at run-time. Alternatively, compilers could just insert runtime checks. To some degree this can be done with the undefined-behavior sanitizer. So a language with a lot of undefined behavior such as C can be both: relatively safe or fast depending on the compiler options. In the past, the later option has been neglected by compiler writers but this is changing.
There are some deficiencies in C which I think can be fixed by adding a couple of minor features (e.g. certain attributes which can provide information for static analysis). The biggest problem in my opinion is that the standard library is so small, so programmers often write there own open-coded alternatives which then tend to be buddy and unsafe instead where other languages offer well-defined APIs and carefully implemented algorithms.
There is only a problem if you think everything published in science must be true. This isn't the case and never was. There was a time, there was no peer review. And also otherwise good journals sometimes publish bad papers. So the solution for scientists is obvious: Do not believe everything you read. If a bad journal published only bad science, nobody will bother to read it and people who publish there do not gain reputation. So there is not really a problem for science... It is a problem though for stupid journalists who think every published article must be true or for stupid committees who judge applicants by the number of publications in peer-reviewed journals. If "fake" journals help getting rid of this stupidity, this can only be a good thing.
Having said this, there are definitely problem in science we need to address: And even the high-ranking journals often have standards which are too low in terms of weak statistics, clear descriptions, openness of data and code, etc.