As you correctly point out solar is good for peak load. Nuclear has the opposite problem: it is only good for base load while demand changes a lot during the day. So you would need a storage component as well if you want to power everything with nuclear.
But you you can mix energy sources. Solar + wind is relatively stable in Germany and instead of having storage, you can ramp down other energy sources and save fuel (hydropower, biomass, gas, coal). You can also export and import electricity and average production over a large area.
With respect to solar subventions: It is much to pay the subventions via energy prices than with general taxes (as has been done with nuclear) to avoid the rebound effect.
So, yes, I think the German way is very rational. (I am a German physicist living in California - which BTW is not too different with having almost no nuclear anymore and going green.)
The dramatic increase in human life an health of the last 500 years has been driven by the ingenuity and hard work of many people. Many of them have not been motivated by profit.
I suspect they're unifying memory and local storage in a more fundamental way. It would sure make life easier if you could (in user space) just mark some memory as "persistent" when you allocate it, and let the OS worry about caching and performance, but doing that right isn't easy or obvious.
You create and mmap a file. There is your persistent memory.
Ah, the "X11 is not network transparent anymore" FUD. How is this moderated insightful? I use it everyday - between different machines with different versions of UNIX or Linux and it just works. People want to break this for no good reason, and this is really really sad.
And yes, applications which do not use direct rendering (i.e. 99%) do render in exactly the same way (using XRender).
The report does not argee with you. The report pretty much exclusively talks about the failure of the crew to manage and understand the situation as the causes of this accident. (Page 199, 3.2. Causes of the Accident).
Also, there was *no* mechanical failure. Icing of the Pitot probes is not a mechanical failure. The word "mechanical failure" does not appear in the report.
No, the fact of human-caused global warming is disputed. And this, while the science is very very clear. Not believing in human-caused climate science is on the same level of stupidity as homoepathy. But global warming requires government regulations to get it fixed, "the market" can not do it by itself. But if you believe in the ideology that the market can do everything, then global warming simply cannot exist. It is not a question of science anymore, it is relgion. It is that simply. You can observe similar fallacies in many similar arguments (If you are poor/unemployed, it must be because you are lazy. If something is too expensive, well it is the market price, so shut up - it must be the optimal,...). I say this as someone who believes that a functioning market is a great tool to efficiently allocate resources, but one has to understand that it is a tool, which has many limitations and can fail in various ways.
Ofcourse, there are people who benefit tremendously from this idiology. Similar to a Guru in some cult, these people try to convince everybody that this is the truth to stay in control. Unfortunately, even on a tech/science site as slashdot there are many commenters stupid enough to fall for this bullshit.
If you "interact" (I assume you mean copy and re-distribute) with proprietary code is it even more a mine field, because if you copy proprietay code in your project without an explicit license which allows this you cannot do anything anymore (not even use it yourself - which the GPL allows). So if the GPL is cancerous, proprietary code is instant death.
The core science is not in dispute. It is accepted by every established scientific association on the planet, for every branch of science.
Some people claim to know exactly what's going to happen and why. Others claim to know when. But nobody really knows how the atmospheric system works fully yet - none of the models are great predictors yet. We still need better models - even the people who think they have the best models are still writing grants to build better ones!
It's basically accepted by everyone except one political faction in one scientifically illiterate country.
What's accepted? Surely not that we're done with the science! Be careful of people who have religion at either extreme of such debates.
You are right about open questions, but this is just distracting from the only important thing: GP is absolutely right: The _core_ science is not in dispute. All important national academies of science and many scientific societies have issued statements in support of the IPCC. It does not get clearer than this.
Also I am wondering what a statement such as "Be careful of people who have religion at either extreme of such debates" is supposed to mean. Setling for a moderate point of view will certainly make your life easier, but if you search for the truth, you have to accept that the truth might turn out to be something extreme. A much better advise is: Always question your own beliefs. In times of the filter bubble, this seems more important than ever.
Well. I don't think it is overengineered. In fact, I think that X is rather nicely engineered at its core. Admittedly, it accumulated some hacks, but I don't think that this is so bad as usually claimed here in discussions (and never really backed up with concrete examples). Also, I don't think that network transparency has that impact on the design you say (and yes, I have a Xorg source tree checked out here, compared to mozilla or gcc this is not too bad). From a design point of view, X and Wayland are similar: commands go over a socket. For local clients over a UNIX domain socket. So why do you think that network transparency add so much complexity? Yes, one has to support sending buffers of the network in addition to fast local methods (which X also had for a long time), but that does not seem to add a lot of complexity to me. Or, in other words: I simply do not buy the argument that the Wayland design is so much simpler and better, and especially not because it does not have network transparency.
I also disagree that network transparency is not needed. I use it every day and there is a lot of talk on how to add it back to Wayland - in an incompatible way. In fact, thinking a bit of the future, a lot of optimizations for buffer sharing with the GPU will be irrelevant once GPU are fully integrated with the CPU again, while network transpareny will just get more and more important.
Ok. You thank you for agreeing that X is not unfixable. Now we could discuss if this "simplification" is worth breaking API compatiblity. I think it is not: Breaking compatibility is rarely a good thing.
But atleast one is now at a point where one could discuss it. If you look at all the comments here: The discussion is not about this, instead it is full of FUD: X is unfixable broken, X would enforce an outdated rendering model on applications, X is bloated, etc. In truth: The only point of wayland is to make the code simpler by breaking an API which is a decade old.
You: "You just cannot fix X the way it should be fixed." Reality: "... It's entirely possible to incorporate the buffer exchange and update models that Wayland is built on into X..." (Wayland FAQ)
As the developers have mentioned over and over again to their finger in eared critics, there's nothing preventing remote applications, and indeed Weston was shown to have some alpha RDP style code in it.
I would not complain if the Wayland people would just shut up and work on their stuff and once everything is ready *propose* it as an alternative... Instead of declaring it as the future replacement long before even basic functionality it is ready (and I am not talking about network transparency).
I also don't care what kind of RDP stuff the can possible build into Wayland. I need *compatibility*. The huge advantage of X is that is a standard with a huge number of apps, and a protocol which is currently spoken by every Linux and UNIX machine. A switch to Wayland (or MIR) will damage this ecosystem. Linux/Wayland will be different to Linux/X similar to how Android is different. Breaking API compatiblity on the Linux desktop is just insanely stupid. And this is exactly what Wayland is about.
I would say this is exactly what network transparency means. That there are optimizations for local clients does not change this a bit. Similar optimizations have been there forever (MIT SHM).
No. Just no. The ability to remotely display an app does not make it network transparent. If that's what you think then you should be happy that Wayland will allow the exact same "network transparency" you so hold dear.
Network transparency means the app renders in the exact same way regardless of the target, which is just plain false.
Please define "exact same way". Currently, almost all applications (not just xterm, also all others: I commonly use: eog, gnome-terminal, nautilus, evince, gitk....) work just fine over the network. And as far as I see they render in exactly same way (using the X render extension). So please clarify what you mean by "not network transparent". Are you talking about OpenGL applications? Those would render differently (GLX for remote and direct rendering locally), but I think this is handled transparently to the application by the mesa library.
...media buttons...
The media buttons seems the only real argument that comes up. But it is hard to believe that you have to throw out a decade of API compatibility to fix this minor issue. The way that Wayland seems to fix this is to have special support for screen savers. Certainly, one could have a special functonality in X as well.
Modern applications will use the X Rendering extension. The Rendering extension was designed more than 10 years ago to replace the outdated rendering model of X. It was insprired by the network transparent windowing of plan 9 and specifically introduced with network transparency in mind.
You are really calling the people who have been using X for years "noobs"?
Using X does not mean understanding X. Additionally using X does not mean understanding how things have changed under the hood when there's been no visible change in the usability of the system.
Nobody complains about changes under the hood if there are no regressions. Don't beat up a stawman.
Frankly a lot of X veterans who maybe once used X in a truly network transparent way think that just because their ability to send a window to another X system means it's still network transparent, which is utter rubbish.
I would say this is exactly what network transparency means. That there are optimizations for local clients does not change this a bit. Similar optimizations have been there forever (MIT SHM).
There's no modern distro which actually implements remote X in any other way than Wayland is proposing to do it, pixels scraping and sending it over the network.
Well, the design of Wayland is actually not so much different than X. (Still people claim it will magically be much more performant.)
The problem with Wayland is: It breaks compatibility with X without having any real advantage.
Yet for some reason some people are still hung up on a feature which they think they use because frankly they don't understand anything, and the most vocal bunch seems to be the ones with the longest beards.
And the insults don't help your case. You don't have to grow a beard, but a bit of maturity would be nice.
The shoving uncompressed bitmaps is not really the problem. The round trips come from stupid things like creating a lot of atoms in a synchronous way using xlib. This is not a problem with the X protocol and can be avoided using XCB. There was some momentum to get this fixed, before Linux development was re-focussed for the mobile market (just look who funds what and why). Don't be fooled this is not about your desktop. This is especially not about the traditional UNIX desktop which will simply be discarded along the way because it is not of significant commercial interest to anyone. From my perspective, Wayland and MIR are a both disaster, because I fear that it will set us back a decade by breaking compatibility with diffiicult to re-create special applications coded against POSIX and X.
The best outcome now would be a split of the Linux community with one part concentrating on a X11/UNIX desktop and API stability. All other players are then free to continue to create incompatible systems to fulfill their mobile ambitions without hurting the ones which would like to have a stabile UNIX-like system.
PS: xpra is nice, that it breaks the on-the-wire protocol is a big mistake.
But they had the fathom to make a nice and extendable protocol. For example, when people figured out 10 years ago that the old rendering model is not the most approbriate, the Xrender extension was created. The Wayland FAQ acknowledges that you can do everything Wayland does by extending X (and it seems this is what the DRI3 extension is about). The only point of Wayland - and this is openlly admitted in their FAQ - is to get rid of old code by breaking compatibility in the long run. I do not agree with this direction.
Hi, I have to catch a flight. No time to discuss this now. But somehow you think the Wayland developers are "the X developers", who gave up on X. Some Wayland developers are also X developers would be more accurate. And there are other X developers who don't work on Wayland. And even the Wayland developers do not really claim that X is unsuitable for a modern desktops. Just check the Wayland FAQ: it spells out pretty explicitely that you could do everything Wayland does also within X. They just want to get rid of old code, which is currently needed for backwards compatibility. The whole point is Wayland is to break compatibility to get rid of this maintainance burden in the long run. This - IMHO - is stupid. But I guess it depends on how much you value backwards compatibility.
I like the X protocol, one has to use XCB though, to see that it is really nice and well designed. What people call bloat is actually some code needed for backwards compatibility. There is really no bloat in terms of memory or cpu use. DRI3 will bring efficient buffer sharing for local clients similar to Wayland while still maintaining compatibility. Not that I care about these optimizations - I would prefer the Intel guys fix their drivers so that I don't have rendering bugs all the time on my notebook. (The real motivation for all this buffer sharing optimizations does not seem to be performance improvements anyway, but power usage on mobile devices.)
And yes, I also like to have network transparency.
The thing is, a window system is not only about sharing buffers. Otherwise, Wayland would have been finished 5 years ago or so. Do you know what they are doing in all these years? They re-implement all the other stuff, which X already does. You know cut&paste, drag'n'drop, minimizing/maximizing, RandR... But now we have another incompatible API. Sigh.
The Curry-Howard isomorphism is a way to relate programs to proofs and types to propositions. Control flow can be expressed in terms of call/cc and relates to Peirce's law in logic.
Slashdot Mirror
As you correctly point out solar is good for peak load. Nuclear has the opposite problem: it is only good for base load while demand changes a lot during the day. So you would need a storage component as well if you want to power everything with nuclear.
But you you can mix energy sources. Solar + wind is relatively stable in Germany and instead of having storage, you can ramp down other energy sources and save fuel (hydropower, biomass, gas, coal). You can also export and import electricity and average production over a large area.
With respect to solar subventions: It is much to pay the subventions via energy prices than with general taxes (as has been done with nuclear) to avoid the rebound effect.
So, yes, I think the German way is very rational. (I am a German physicist living in California - which BTW is not too different with having almost no nuclear anymore and going green.)
It is called "demand paging". But this is completely transparent to the application... So how does persistent memory change anything?
The dramatic increase in human life an health of the last 500 years has been driven by the ingenuity and hard work of many people. Many of them have not been motivated by profit.
I suspect they're unifying memory and local storage in a more fundamental way. It would sure make life easier if you could (in user space) just mark some memory as "persistent" when you allocate it, and let the OS worry about caching and performance, but doing that right isn't easy or obvious.
You create and mmap a file. There is your persistent memory.
Ah, the "X11 is not network transparent anymore" FUD. How is this moderated insightful? I use it everyday - between different machines with different versions of UNIX or Linux and it just works. People want to break this for no good reason, and this is really really sad.
And yes, applications which do not use direct rendering (i.e. 99%) do render in exactly the same way (using XRender).
Mod parent up. Atleast Valve found that Left 4 Dead 2 run faster after porting OpenGL on Windows (and even faster on Linux).
http://blogs.valvesoftware.com...
The report does not argee with you. The report pretty much exclusively talks about the failure of the crew to manage and understand the situation as the causes of this accident. (Page 199, 3.2. Causes of the Accident).
Also, there was *no* mechanical failure. Icing of the Pitot probes is not a mechanical failure. The word "mechanical failure" does not appear in the report.
Property rights? To the atmosphere? I hope you are joking.
If you mean CO2 certificates, I agree, but they are a combination of regulation and a market model.
And you are saying people are not familiar with property rights, seriously?
No, the fact of human-caused global warming is disputed. And this, while the science is very very clear. Not believing in human-caused climate science is on the same level of stupidity as homoepathy. But global warming requires government regulations to get it fixed, "the market" can not do it by itself. But if you believe in the ideology that the market can do everything, then global warming simply cannot exist. It is not a question of science anymore, it is relgion. It is that simply. You can observe similar fallacies in many similar arguments (If you are poor/unemployed, it must be because you are lazy. If something is too expensive, well it is the market price, so shut up - it must be the optimal, ...). I say this as someone who believes that a functioning market is a great tool to efficiently allocate resources, but one has to understand that it is a tool, which has many limitations and can fail in various ways.
Ofcourse, there are people who benefit tremendously from this idiology. Similar to a Guru in some cult, these people try to convince everybody that this is the truth to stay in control. Unfortunately, even on a tech/science site as slashdot there are many commenters stupid enough to fall for this bullshit.
If you "interact" (I assume you mean copy and re-distribute) with proprietary code is it even more a mine field, because if you copy proprietay code in your project without an explicit license which allows this you cannot do anything anymore (not even use it yourself - which the GPL allows). So if the GPL is cancerous, proprietary code is instant death.
The core science is not in dispute. It is accepted by every established scientific association on the planet, for every branch of science.
Some people claim to know exactly what's going to happen and why. Others claim to know when. But nobody really knows how the atmospheric system works fully yet - none of the models are great predictors yet. We still need better models - even the people who think they have the best models are still writing grants to build better ones!
It's basically accepted by everyone except one political faction in one scientifically illiterate country.
What's accepted? Surely not that we're done with the science! Be careful of people who have religion at either extreme of such debates.
You are right about open questions, but this is just distracting from the only important thing: GP is absolutely right: The _core_ science is not in dispute. All important national academies of science and many scientific societies have issued statements in support of the IPCC. It does not get clearer than this.
Also I am wondering what a statement such as "Be careful of people who have religion at either extreme of such debates" is supposed to mean. Setling for a moderate point of view will certainly make your life easier, but if you search for the truth, you have to accept that the truth might turn out to be something extreme. A much better advise is: Always question your own beliefs. In times of the filter bubble, this seems more important than ever.
Well. I don't think it is overengineered. In fact, I think that X is rather nicely engineered at its core. Admittedly, it accumulated some hacks, but I don't think that this is so bad as usually claimed here in discussions (and never really backed up with concrete examples). Also, I don't think that network transparency has that impact on the design you say (and yes, I have a Xorg source tree checked out here, compared to mozilla or gcc this is not too bad). From a design point of view, X and Wayland are similar: commands go over a socket. For local clients over a UNIX domain socket. So why do you think that network transparency add so much complexity? Yes, one has to support sending buffers of the network in addition to fast local methods (which X also had for a long time), but that does not seem to add a lot of complexity to me. Or, in other words: I simply do not buy the argument that the Wayland design is so much simpler and better, and especially not because it does not have network transparency.
I also disagree that network transparency is not needed. I use it every day and there is a lot of talk on how to add it back to Wayland - in an incompatible way. In fact, thinking a bit of the future, a lot of optimizations for buffer sharing with the GPU will be irrelevant once GPU are fully integrated with the CPU again, while network transpareny will just get more and more important.
Ok. You thank you for agreeing that X is not unfixable. Now we could discuss if this "simplification" is worth breaking API compatiblity. I think it is not: Breaking compatibility is rarely a good thing.
But atleast one is now at a point where one could discuss it. If you look at all the comments here: The discussion is not about this, instead it is full of FUD: X is unfixable broken, X would enforce an outdated rendering model on applications, X is bloated, etc. In truth: The only point of wayland is to make the code simpler by breaking an API which is a decade old.
You: "You just cannot fix X the way it should be fixed."
Reality: "... It's entirely possible to incorporate the buffer exchange and update models that Wayland is built on into X..." (Wayland FAQ)
And now?
And both are now incompatible ecosystems. Do we want to repeat this nonsense?
I don't see how this constitutes an argument: Nazis calling other Nazis jews. I would recommend not to look at Nazi websites for political education.
This is used for propaganda by the Russians, but it seems there are Neo-Nazis in Ukraine's new government.
http://en.wikipedia.org/wiki/S...
http://en.wikipedia.org/wiki/O...
As the developers have mentioned over and over again to their finger in eared critics, there's nothing preventing remote applications, and indeed Weston was shown to have some alpha RDP style code in it.
I would not complain if the Wayland people would just shut up and work on their stuff and once everything is ready *propose* it as an alternative... Instead of declaring it as the future replacement long before even basic functionality it is ready (and I am not talking about network transparency).
I also don't care what kind of RDP stuff the can possible build into Wayland. I need *compatibility*. The huge advantage of X is that is a standard with a huge number of apps, and a protocol which is currently spoken by every Linux and UNIX machine. A switch to Wayland (or MIR) will damage this ecosystem. Linux/Wayland will be different to Linux/X similar to how Android is different. Breaking API compatiblity on the Linux desktop is just insanely stupid. And this is exactly what Wayland is about.
I would say this is exactly what network transparency means. That there are optimizations for local clients does not change this a bit. Similar optimizations have been there forever (MIT SHM).
No. Just no. The ability to remotely display an app does not make it network transparent. If that's what you think then you should be happy that Wayland will allow the exact same "network transparency" you so hold dear.
Network transparency means the app renders in the exact same way regardless of the target, which is just plain false.
Please define "exact same way". Currently, almost all applications (not just xterm, also all others: I commonly use: eog, gnome-terminal, nautilus, evince, gitk....) work just fine over the network. And as far as I see they render in exactly same way (using the X render extension). So please clarify what you mean by "not network transparent". Are you talking about OpenGL applications? Those would render differently (GLX for remote and direct rendering locally), but I think this is handled transparently to the application by the mesa library.
...media buttons...
The media buttons seems the only real argument that comes up. But it is hard to believe that you have to throw out a decade of API compatibility to fix this minor issue. The way that Wayland seems to fix this is to have special support for screen savers. Certainly, one could have a special functonality in X as well.
Modern applications will use the X Rendering extension. The Rendering extension was designed more than 10 years ago to replace the outdated rendering model of X. It was insprired by the network transparent windowing of plan 9 and specifically introduced with network transparency in mind.
http://keithp.com/~keithp/talk...
(see the conclusion)
You are really calling the people who have been using X for years "noobs"?
Using X does not mean understanding X. Additionally using X does not mean understanding how things have changed under the hood when there's been no visible change in the usability of the system.
Nobody complains about changes under the hood if there are no regressions. Don't beat up a stawman.
Frankly a lot of X veterans who maybe once used X in a truly network transparent way think that just because their ability to send a window to another X system means it's still network transparent, which is utter rubbish.
I would say this is exactly what network transparency means. That there are optimizations for local clients does not change this a bit. Similar optimizations have been there forever (MIT SHM).
There's no modern distro which actually implements remote X in any other way than Wayland is proposing to do it, pixels scraping and sending it over the network.
Well, the design of Wayland is actually not so much different than X. (Still people claim it will magically be much more performant.)
The problem with Wayland is: It breaks compatibility with X without having any real advantage.
Yet for some reason some people are still hung up on a feature which they think they use because frankly they don't understand anything, and the most vocal bunch seems to be the ones with the longest beards.
And the insults don't help your case. You don't have to grow a beard, but a bit of maturity would be nice.
The shoving uncompressed bitmaps is not really the problem. The round trips come from stupid things like creating a lot of atoms in a synchronous way using xlib. This is not a problem with the X protocol and can be avoided using XCB. There was some momentum to get this fixed, before Linux development was re-focussed for the mobile market (just look who funds what and why). Don't be fooled this is not about your desktop. This is especially not about the traditional UNIX desktop which will simply be discarded along the way because it is not of significant commercial interest to anyone. From my perspective, Wayland and MIR are a both disaster, because I fear that it will set us back a decade by breaking compatibility with diffiicult to re-create special applications coded against POSIX and X.
The best outcome now would be a split of the Linux community with one part concentrating on a X11/UNIX desktop and API stability. All other players are then free to continue to create incompatible systems to fulfill their mobile ambitions without hurting the ones which would like to have a stabile UNIX-like system.
PS: xpra is nice, that it breaks the on-the-wire protocol is a big mistake.
But they had the fathom to make a nice and extendable protocol. For example, when people figured out 10 years ago that the old rendering model is not the most approbriate, the Xrender extension was created. The Wayland FAQ acknowledges that you can do everything Wayland does by extending X (and it seems this is what the DRI3 extension is about). The only point of Wayland - and this is openlly admitted in their FAQ - is to get rid of old code by breaking compatibility in the long run. I do not agree with this direction.
Hi, I have to catch a flight. No time to discuss this now. But somehow you think the Wayland developers are "the X developers", who gave up on X. Some Wayland developers are also X developers would be more accurate. And there are other X developers who don't work on Wayland. And even the Wayland developers do not really claim that X is unsuitable for a modern desktops. Just check the Wayland FAQ: it spells out pretty explicitely that you could do everything Wayland does also within X. They just want to get rid of old code, which is currently needed for backwards compatibility. The whole point is Wayland is to break compatibility to get rid of this maintainance burden in the long run. This - IMHO - is stupid. But I guess it depends on how much you value backwards compatibility.
I like the X protocol, one has to use XCB though, to see that it is really nice and well designed. What people call bloat is actually some code needed for backwards compatibility. There is really no bloat in terms of memory or cpu use. DRI3 will bring efficient buffer sharing for local clients similar to Wayland while still maintaining compatibility. Not that I care about these optimizations - I would prefer the Intel guys fix their drivers so that I don't have rendering bugs all the time on my notebook. (The real motivation for all this buffer sharing optimizations does not seem to be performance improvements anyway, but power usage on mobile devices.)
And yes, I also like to have network transparency.
The thing is, a window system is not only about sharing buffers. Otherwise, Wayland would have been finished 5 years ago or so. Do you know what they are doing in all these years? They re-implement all the other stuff, which X already does. You know cut&paste, drag'n'drop, minimizing/maximizing, RandR... But now we have another incompatible API. Sigh.
The Curry-Howard isomorphism is a way to relate programs to proofs and types to propositions. Control flow can be expressed in terms of call/cc and relates to Peirce's law in logic.