Let me comment on the beach thing (no I did not watch the youtube video) and the general idea that natural background radiation does not contribute to cancer or even have a beneficial effect. This is clearly not a mainstream scientific opinion. In fact, the opposite is true. I just spent a few minutes searching for reviews (so this is not a comprehensive review of the literature), but just a few examples:
Jolyon H Hendry et al 2009 J. Radiol. Prot. 29 A29 Human exposure to high natural background radiation: what can it teach us about radiation risks?
This article basically states that we have no direct evidence for most areas with high natural background radiation (HBNR) because the effect is too small (but also no evidence for no effecit or even a beneficial effect), but we have evidence for example for populations in areas with high radon levels:
"Much of the direct information about risk related to HNBR comes from caseâ"control studies of radon and lung cancer, which provide convincing evidence of an association between long-term protracted radiation exposures in the general population and disease incidence."
Mehdi Sohrabi, World high background natural radiation areas: Need to protect public from radiation exposure. Radiation Measurements, Volume 50, March 2013, Pages 166â"171
This is interesting because he specifically discusses the areas you mention:
"There it was found that the radiation level in Guarapari can be considered as normal except at hot spots on the beaches and in the fishing village of Meaipe (Sachett, 2002)."
It also mentions previous studies in two areas with high background radiation in Brazil which finds elevated cancer rates, (also this is probably not caused by radiation). But this contradicts your anectode that people are super healthy there.
Another review:
MÃller, A. P. and Mousseau, T. A. (2013), The effects of natural variation in background radioactivity on humans, animals and other organisms. Biological Reviews, 88: 226â"254.
From the conclusion: "1. We reviewed the literature on responses to natural variation in background radiation. There was evidence of a significant, but small effect of natural variation in background radiation on mutation rates, DNA damage and DNA repair. 2. There were significant effects of natural variation in background radiation on immunology and disease including cancer. 3. The findings reported here are inconsistent with a general role of hormesis from low levels of natural background radiation. 4...."
Sorry, as much as I would love to, but I have no time to discuss this with random people on the internet anymore.
I just pointing out that the scientific community generally accepts the LNT. If you have a different opinion - please write down what you think is "obvious" and submit to a journal. E.g. if you find a math error in a published study, please write a letter to the editor of the journal. You will soon find out, that it is not as obvious as you think. Do you really think scientists don't know about Three Mile Island, about intercontinental air traffic or places with higher natural radiation?
Finally, even if you believe the LNT is not true: A first step to a serious discussion is to acknowledge that the scientific community generally does accept it (and yes, I know it has been challenged). I gave you a reference to a review in a prestigious journal summarizing our current understanding. So please stop running around telling that it is BS because no MD or PhD would defend it youtube or similar nonsense.
The thing is, government subsidies and un-accounted external effects (health, CO2) mask the true costs of all kinds of energy. Nuclear would not even exist without a lot of governement funded research. The German subsidies for green seen actually not unreasonable high compared to former and current Nuclear subsidies, and there is reason to believe that this is money well spent. The difference is that they have been implemented by imposing a fee on electricity, and are not paid with general taxes.This was intentional to not have subsidies on the production side, but to penalize consumption, i.e. to avoid induced demand. This is smart, but puts a larger burden on low-income households.
It discusses various aspects and acknowledges that there might be non-linear effects and low doses which are not yet completely understood. However, I want to give two quotes that make clear that the LNT is the currently accepted standard:
From the introduction: "The current generally accepted pragmatic approach to low-dose risk estimation recommended for the regulation of radiation exposures and endorsed by the Biological effects of ionizing radiations (BEIR) VII report of the US National Academy of Sciences 12 and the International Commission on Radiological Protection (ICRP) 13 is that a linear non-threshold (LNT) extrapolation of cancer risk from high-dose data is most appropriate (FIG. 1) . The LNT model implies that there is an increase in risk to health proportionate to the radiation dose received down to the very lowest levels. The model indicates that there is no safe level of exposure -- that is, there is no threshold dose below which no increase in risk to health is posed."
And from the conclusion:
"However, there remains a lack of understanding regarding how the cellular- and tissue-level responses to radiation, be they linear or nonlinear, in aggregate affect cancer risk. Without this knowledge, uncertainty will remain in the cancer risk estimates for low-dose radiation. Nonetheless, the results discussed in this article do not provide compelling evidence to abandon the LNT approach adopted for radiation protection."
For me the main point is compatibility. Even when one desires better network performance, I see no reason why this can not be achieved with the X protocol (or an extension) in a compatible way. I think the Wayland design is not bad and I don't doubt that it is theoretically possible to also add a good network protocol to it, but by not being compatible it will - in the long term - destroy the huge advantage that you can now use 'ssh -X' basically from every Linux/UNIX to every other and it just works.
Now, this might not be important to everyhone, but what pisses me off is the arrogance on how it is declared that it is not important and you should simply shut up about it. (And I rarely got some much insults and 'troll' moderation as in this thread.) Or you are told that this does not matter because "network transparency is already broken", which is simply not true because I use it every single day.
It doesn't though. One one side it talks as a compositor and ICCCM to clients that are going to be displayed elsewhere. The X clients talk X to a dummy X server that runs on the 'remote' end. Then it has it's own protocol to convey encoded graphical content and contextual data gleaned from being the compositor and ICCCM.
You are right. I was a while since a looked at it, I must have confused it with NX which uses the X protocol I think.
Xpra acheives great result precisely by avoiding use of X *at all* for network transparency.
Sorry it don't buy this. How does avoiding the X protocol achieve anything? You can move pixels with X as well. The problem with having a different protocol is, it breaks every X functionality which is not explicitely supported. For example, different X clients can make up a new protocol to coordinate with each via the X server without the X server having any specific knowledge about this (e.g. having to be upgraded). This is useful: For example, new window manager behaviour can be implemented without having to upgrade every server. How would this work with xpra?
It is able then to get away with a *much simpler* protocol, trivially provide session persistence, and beat the pants off of ssh -X performance wise to boot.
The advantage you see is probably by eliminating a lot of round trips by having a local server. This would eliminate all the latency from stupid clients which do a series of synchronuos rquests using xlibs. This is a known problem with xlib. This could be fixed either by fixing the clients or by having a local proxy xserver (as NX and xpra do), but I don't see what this has to do with having another protocol.
Which of course leads me to a point of some heresy. I don't know if it's worth it to replace X as the protocol between graphical clients and servers, but I for one think it *is* very much worth it to stop thinking of the X protocol as the best means of providing network transparent remote application access.
Well, my point is: Why not do it with the X protocol? That you can do something without X protocoll does not imply you cannot do with X protocol (in fact NX demonstrates that this). Even if something is missing it is easy to extend the protocol. I don't see any inherent flaw in the X core protocol which could justify to abandon decades of compatibility.
Yes, RDP doesn't do the job as implemented by microsoft (the per application mode is still not seamless), but Xpra has demonstrated precisely how good remote seamless applications can be in a world without using X as the transport.
Yes, but that does not imply the reverse: that you can have this only in a world without using X as the transport. Why not have both? Performance and backwards compatibility?
As such I think it would be bad for the Linux community if distributions switch to it by default.
They could silently switch to Wayland with X11 on top of it and nobody would notice anything, even the peoples running old gtk 1.2 apps.
Ofcourse, if Wayland was just a different backend for X11 introduced I would not complaining. But it is not, it is a replacement API with a compatibility layer on top. With this compatibility layer the overall system got even more complicated, instead of simpler. But the goal seems to be to get rid of X entirely, i.e. to break compatibility. This is the direction I don't agree with.
None of your complain against Wayland is valid. Xorg could have been designed that way (Separate framebuffer backend 'a la wayland' plus x11 protocol on top) from the start and you would have defend that model with the same obsessive fervour. Try to program with Xlib some day...
I gave a very good reason for my statement above which you failed to quote: "it breaks compatibility and has no network transparency while having no advantage which could not also be achieved with X". How is this invalid? You are again answering with insults (obsessive fervour) instead of arguments.
This is even worse. So you need to have every toolkit installed on both sides to make it work?
Yep.
Also you are missing my point. Upgrade GTK from one version to another, does it still work?
Both sides are going to need the widget set the application was compiled against. So minor versions will generally be fine but full version numbers you'll need both.
That is a deal breaker right here. How can this ever work? I use ssh to connect to three/four major different institutions each with different departments with computers maintained by different teams. You want the world so sync there software to a single version for every toolkit? Get real. (you are talking about vapourware anyway, because all this does currently not exist on the Wayland side).
Also, X is a very flexible protocol. Toolkits could already apply deep knowledge if they wanted to and if X is missing something on the server side, this could be added as an extension in a backwards compatible way.
How? The X protocol limits what can be sent and what sorts of queries can be used.
You can define extensions and this has been done in the past. X evolved a lot in this way. So in what sense does X limit what sorts of queries can be used?
It limits things like traffic shaping.
How?
There is no way for an X11 app to do a simple request like "do you want me to generate a virtual PDF and send that to you, or do you want the low level print stream to forward to a local printer and if so what format do you want the stream in?"
This is funny. X has been criticized for having things like having an extension for printing. Ofcourse, you could have an extension which negotiates with the client on how a document should be sent to a printer.
They want to create another incompatible protocol?
No they want to create several. One per widget set. So Qt/KDE would have one, GTK/Gnome would have one. Then there likely would be others like Enlightenment / EWL. Each protocol is going to be smart about respective applications.
So I need to have every toolkit installed everywhere? (and the same version?)
Also, why can toolkits not be smart using a very generic protocol such as X?
I don't see what you mean by applications and graphics are shared?
Can an application write directly to the graphics buffer or not? If yes you get performance and no network transparency. If no you get network transparency but take a performance hit.
If with graphics buffer you mean a buffer in the server, X had shared memory extenion as an optimization. So yes, you can have both: You use shared memory on local clients and push it ver the network for remote clients. If you mean a buffer on the graphics card, i.e. direct rendering, then X has this is as an optimization for local clients as well. But yes, direct rendering on X was messy, but it seems it gets fixed on X with DRI3 in basically the same way as Wayland also does it.
But I have very good performance with 'ssh -X' from home to work so it is working for me and it is very simple.
You aren't getting good efficiency.
Efficiency in terms of what? In terms of volume? Why would this be more with ssh?
Good performance is a result of just using a ton of resources. Lots of problems go away if you throw enough hardware at them. SSH will fall apart very quickly if you start not giving it enough resources. More robust protocols will be able to shape traffic more effectively. Try it by limiting traffic on a VM.
I don't see why: Could you give a technical why this should be true with ssh as a transport. Maybe you are thinking about general stream based transports (e.g. TCP) and UDP might be more efficient? As far as I know RDP uses also TCP as a transport layer. But anyway, tunneling through ssh solves so many practical problems that any other method wlll basically also have to support this even if it is less efficient. Or, no matter how efficient, if it can use ssh as a tunnel it is not nearly as useful.
Wayland is not supposed to be only a backend for X.
So you admit Wayland is more flexible and therefore superior software and you still cringe to the obsolete x11 windowing system?
No. What makes you think this?
The other thing which I really love about Wayland is how friendly its fanboys are;-)
Implying that i am a fanboy? I write software using Xlib, I understand it's limitation. I also see that your arguments against Wayland make no sense. Adding both make me think Wayland might not be so bad since only idiots seem to hate it with a passion. I intent to look into it when it's packaged in Debian.
Well, you are one acting like a child by insulting people ("shut up", "idiots"") instead of having a discussion. I also don't hate Wayland, I just point out that it breaks compatibility and has no network transparency while having no advantage which could not also be achieved with X. As such I think it would be bad for the Linux community if distributions switch to it by default.
With X11 you need an X-protocol speaking Xserver on the server side and and X-protocol speaking client on the client side (this could use xlib or xcb or something else). The point is that this protocol has been a standard.
I will suggest looking into Xpra. I'm personally wary of RDP as the specific solution unless it deviates from MS design significantly, but Xpra at least seems to me a proof point that the 'ssh -X' way is no longer the only way.
I know Xpra, it is nice, although I don't need it. But I don't get your point, it uses 'ssh -X'.
Xpra acheives everything I like about ssh -X, but it performs way better and sessions are not hopelessly broken if the connection is lost. It manages to acheive this by sitting between X server and clients as the window manager/compositor rather than actually using the X protocol to acheive it.
But Xpra speaks X on both sides! It only demonstrates that this can be achieved with X - without inventing a new network protocol. In fact, support for reconnecting (moving to another display) could added to clients (and some can do it). Sadly, toolkit developers have other priorities.
Of course I'm not convinced there is such a dire need to replace X at all, but at least I'm open to the possibility that there is a nice and clean mechanism to add X level network transparency by way of the compositor/window manager rather than the relationship between applications and the display server.
The point is: There is no need to invent a new incompatible protocol to do all this. It could be done in a compatible way. I see considerable harm to Linux by breaking compatibility without a good reason.
They are talking about RDP like design not RDP itself. RDP is designed for Windows. Wayland's RDP is going to be designed for Wayland.
They want to create another incompatible protocol?
You could achieve everything Wayland does also by extending X without breaking compatibility.
No you can't. Either applications and graphics are shared or they aren't. There are real tradeoffs of one vs. the other. You can't achieve everything, you have to pick.
I don't see what you mean by applications and graphics are shared? Wayland also separates into a server and clients which communicate with a similar protocol as X. Compositing manger and window manager seem to be merged in Wayland. You could also do this with X if you wanted to. Overall, Wayland is very similar in design to X, but incompatible, without compatibility, and without network transparency. And let me quote from the Wayland FAQ "It's entirely possible to incorporate the buffer exchange and update models that Wayland is built on into X."
X over WAN. You use it over ssh or ipsec. Then there is no security problem.
SSH doesn't know what's going on inside X and the network can't see what's going on inside the ssh session. Which means you get worst possible network performance if you use SSH.
I was replying to your point that there is a security problem: There is not.
On the assumption that you are right and ssh is not optimal for performance, you could use ipsec. This has exactly nothing to do with X as a network protocol. But I have very good performance with 'ssh -X' from home to work so it is working for me and it is very simple.
I hope I will have X for years. But I fear that 1) they force Wayland down on us via a default upgrade path like other recent GUI breakage and 2) they UNIX ecosystem will be harmed in irreparable way because they break backwards and forwards compatibility.
This is even worse. So you need to have every toolkit installed on both sides to make it work? Also you are missing my point. Upgrade GTK from one version to another, does it still work? This is only possible with some standardization. So you even want to re-invent X multiple times in in-compatible ways.
Also, X is a very flexible protocol. Toolkits could already apply deep knowledge if they wanted to and if X is missing something on the server side, this could be added as an extension in a backwards compatible way.
You always have a client and a server if you want to have a windows system, including wayland. An no, X does not emulate a freaking network with high latency on local systems. On local clients, it sends messages over a UNIX domain sockets just like Wayland. So no, there is no difference here - Wayland has basically the same design.
The other stuff you are talking about is direct rendering. Yes, direct rendering on X has been a mess. It is an optimization for local clients which want to have direct access to the graphics hardware. A usual desktop does not need it at all. But yes, better DRI would be nice, and Wayland provides this - but exactly the same can also be achieved by changing the DRI in X. The only thing which speaks for Wayland is that you could get rid some of the old obsolete code in X. But this is only true if you don't want backwards compatibility. In that case, you have to maintain that code anyway, and the overall design gets more complex - instead of simpler.
Migrating X clients. This is not a limitation of X. Some X clients can do it (see libdisplaymigration from the GPE palm desktop environment) and you could add it to others with a LD_PRELOAD hack. I always wondered why the toolkits did not add it. It would be a really useful feature. Much more useful than wobbling windows or all the other crap we got.
And everytime you upgrade the toolkit on one end it breaks? You need a standardized protocol which has a stable core and is also flexible and can be extended in the future.Then you have reinvented X.
Well, last time I tried to connect to a Windows machine using RDP the client (actually all I tried which I think were all distributed with Ubuntu) crashed because of some unsupported authentication mode or something. Previously, I had other kinds of problems. Maybe the situation is better on Windows. But before threatening to replace X with RDP, I think we should have at least one RDP client which works well.
And anyway, RDP is not an argument for Wayland anyway, because you can use it with X as well - if you like it. This is in general the main problem I have with Wayland: There are NO real advantages - except getting rid of some old code, but only if you break compatibility (otherwise, it simply lives elsewhere). You could achieve everything Wayland does also by extending X without breaking compatibility.
And compatibility goes both ways. Wayland application will not work on X. This is bad. It breaks the ecosytem for no good reason. But also compatibility with X applications will suffer from being an optional compatibility hack. The Jolla phone already ships without X. Another incompatible system!
Easyness. You are talking about performance instead. I know that X can suck when you have low latency connection - but this depends on the application. This is not really a fundamental problem of the X protocol and could be fixed by not using synchronous requests with Xlib.
X over WAN. You use it over ssh or ipsec. Then there is no security problem.
Finally, I am not saying you should not use Wayland if it is better for you. But I am told that I will have to stop using X in the near future while I think it is better for me. You see the difference? I don't care what you use. But I don't want to be switched over by default with my next upgrade. If Wayland is better, offer it as an alternative which people can switch to if they want to try it. If nobody uses X anymore because everybody voted for Wayland by switching, then you can make it the default. So please distributions, freedesktop, gnome and KDE people, please stop breaking my GUI by forcing random changes onto me with every upgrade. This is the Microsoft way - not the free software way.
Slashdot Mirror
TL;DR
But why do you feel that the ramblings of a fiction author with a known interest in the paranormal are relevant in a scientific debate?
Let me comment on the beach thing (no I did not watch the youtube video) and the general idea that natural background radiation does not contribute to cancer or even have a beneficial effect. This is clearly not a mainstream scientific opinion. In fact, the opposite is true. I just spent a few minutes searching for reviews (so this is not a comprehensive review of the literature), but just a few examples:
Jolyon H Hendry et al 2009 J. Radiol. Prot. 29 A29
Human exposure to high natural background radiation: what can it teach us about radiation risks?
This article basically states that we have no direct evidence for most areas with high natural background radiation (HBNR) because the effect is too small (but also no evidence for no effecit or even a beneficial effect), but we have evidence for example for populations in areas with high radon levels:
"Much of the direct information about risk related to HNBR comes from caseâ"control studies of radon and lung cancer, which provide convincing evidence of an association between long-term protracted radiation exposures in the general population and disease incidence."
Mehdi Sohrabi, World high background natural radiation areas: Need to protect public from radiation exposure.
Radiation Measurements,
Volume 50, March 2013, Pages 166â"171
This is interesting because he specifically discusses the areas you mention:
"There it was found that the radiation level in Guarapari can be considered as normal except at hot spots on the beaches and in the fishing village of Meaipe (Sachett, 2002)."
It also mentions previous studies in two areas with high background radiation in Brazil which finds elevated cancer rates, (also this is probably not caused by radiation). But this contradicts your anectode that people are super healthy there.
Another review:
MÃller, A. P. and Mousseau, T. A. (2013), The effects of natural variation in background radioactivity on humans, animals and other organisms. Biological Reviews, 88: 226â"254.
From the conclusion: ..."
"1. We reviewed the literature on responses to natural variation in background radiation. There was evidence of a significant, but small effect of natural variation in background radiation on mutation rates, DNA damage and DNA repair.
2. There were significant effects of natural variation in background radiation on immunology and disease including cancer.
3. The findings reported here are inconsistent with a general role of hormesis from low levels of natural background radiation.
4.
Sorry, as much as I would love to, but I have no time to discuss this with random people on the internet anymore.
I just pointing out that the scientific community generally accepts the LNT. If you have a different opinion - please write down what you think is "obvious" and submit to a journal. E.g. if you find a math error in a published study, please write a letter to the editor of the journal. You will soon find out, that it is not as obvious as you think. Do you really think scientists don't know about Three Mile Island, about intercontinental air traffic or places with higher natural radiation?
Finally, even if you believe the LNT is not true: A first step to a serious discussion is to acknowledge that the scientific community generally does accept it (and yes, I know it has been challenged). I gave you a reference to a review in a prestigious journal summarizing our current understanding. So please stop running around telling that it is BS because no MD or PhD would defend it youtube or similar nonsense.
Case in point, GB had to offer investors garantueed energy prices 2x the current market price to get them to invest in a nuclear power plant.
http://www.independent.co.uk/n...
This is because Germany now uses coal power plants instead of nuclear plants to produce the necessary electricity.
Not really true, I posted numbers here:
http://slashdot.org/comments.p...
The thing is, government subsidies and un-accounted external effects (health, CO2) mask the true costs of all kinds of energy. Nuclear would not even exist without a lot of governement funded research. The German subsidies for green seen actually not unreasonable high compared to former and current Nuclear subsidies, and there is reason to believe that this is money well spent. The difference is that they have been implemented by imposing a fee on electricity, and are not paid with general taxes.This was intentional to not have subsidies on the production side, but to penalize consumption, i.e. to avoid induced demand. This is smart, but puts a larger burden on low-income households.
For those who are interested into the true state of the scientific kowledge, this seems to be a good review from Nature Reviews Cancer:
http://www.nature.com/nrc/jour...
It discusses various aspects and acknowledges that there might be non-linear effects and low doses which are not yet completely understood. However, I want to give two quotes that make clear that the LNT is the currently accepted standard:
From the introduction:
"The current generally accepted pragmatic approach to low-dose risk estimation recommended for the regulation of radiation exposures and endorsed by the Biological effects of ionizing radiations (BEIR) VII report of the US National Academy of Sciences 12 and the International Commission on Radiological Protection (ICRP) 13 is that a linear non-threshold (LNT) extrapolation of cancer risk from high-dose data is most appropriate (FIG. 1) . The LNT model implies that there is an increase in risk to health proportionate to the radiation dose received down to the very lowest levels. The model indicates that there is no safe level of exposure -- that is, there is no threshold dose below which no increase in risk to health is posed."
And from the conclusion:
"However, there remains a lack of understanding regarding how the cellular- and tissue-level responses to radiation, be they linear or nonlinear, in aggregate affect cancer risk. Without this knowledge, uncertainty will remain in the cancer risk estimates for low-dose radiation. Nonetheless, the results discussed in this article do not provide compelling evidence to abandon the LNT approach adopted for radiation protection."
You base your opinion of how many people defend something on youtube? Seriously? No wonder you think LNT is BS.
Please see one level above for my reply, it seems I replied to myself.
For me the main point is compatibility. Even when one desires better network performance, I see no reason why this can not be achieved with the X protocol (or an extension) in a compatible way. I think the Wayland design is not bad and I don't doubt that it is theoretically possible to also add a good network protocol to it, but by not being compatible it will - in the long term - destroy the huge advantage that you can now use 'ssh -X' basically from every Linux/UNIX to every other and it just works.
Now, this might not be important to everyhone, but what pisses me off is the arrogance on how it is declared that it is not important and you should simply shut up about it. (And I rarely got some much insults and 'troll' moderation as in this thread.) Or you are told that this does not matter because "network transparency is already broken", which is simply not true because I use it every single day.
But Xpra speaks X on both sides!
It doesn't though. One one side it talks as a compositor and ICCCM to clients that are going to be displayed elsewhere. The X clients talk X to a dummy X server that runs on the 'remote' end. Then it has it's own protocol to convey encoded graphical content and contextual data gleaned from being the compositor and ICCCM.
You are right. I was a while since a looked at it, I must have confused it with NX which uses the X protocol I think.
Xpra acheives great result precisely by avoiding use of X *at all* for network transparency.
Sorry it don't buy this. How does avoiding the X protocol achieve anything? You can move pixels with X as well. The problem with having a different protocol is, it breaks every X functionality which is not explicitely supported. For example, different X clients can make up a new protocol to coordinate with each via the X server without the X server having any specific knowledge about this (e.g. having to be upgraded). This is useful: For example, new window manager behaviour can be implemented without having to upgrade every server. How would this work with xpra?
It is able then to get away with a *much simpler* protocol, trivially provide session persistence, and beat the pants off of ssh -X performance wise to boot.
The advantage you see is probably by eliminating a lot of round trips by having a local server. This would eliminate all the latency from stupid clients which do a series of synchronuos rquests using xlibs. This is a known problem with xlib. This could be fixed either by fixing the clients or by having a local proxy xserver (as NX and xpra do), but I don't see what this has to do with having another protocol.
Which of course leads me to a point of some heresy. I don't know if it's worth it to replace X as the protocol between graphical clients and servers, but I for one think it *is* very much worth it to stop thinking of the X protocol as the best means of providing network transparent remote application access.
Well, my point is: Why not do it with the X protocol? That you can do something without X protocoll does not imply you cannot do with X protocol (in fact NX demonstrates that this). Even if something is missing it is easy to extend the protocol. I don't see any inherent flaw in the X core protocol which could justify to abandon decades of compatibility.
Yes, RDP doesn't do the job as implemented by microsoft (the per application mode is still not seamless), but Xpra has demonstrated precisely how good remote seamless applications can be in a world without using X as the transport.
Yes, but that does not imply the reverse: that you can have this only in a world without using X as the transport. Why not have both? Performance and backwards compatibility?
Don't worry. I am not offended by anything a coward says. I just tells something about your character.
As such I think it would be bad for the Linux community if distributions switch to it by default.
They could silently switch to Wayland with X11 on top of it and nobody would notice anything, even the peoples running old gtk 1.2 apps.
Ofcourse, if Wayland was just a different backend for X11 introduced I would not complaining. But it is not, it is a replacement API with a compatibility layer on top. With this compatibility layer the overall system got even more complicated, instead of simpler. But the goal seems to be to get rid of X entirely, i.e. to break compatibility. This is the direction I don't agree with.
None of your complain against Wayland is valid. Xorg could have been designed that way (Separate framebuffer backend 'a la wayland' plus x11 protocol on top) from the start and you would have defend that model with the same obsessive fervour. Try to program with Xlib some day...
I gave a very good reason for my statement above which you failed to quote: "it breaks compatibility and has no network transparency while having no advantage which could not also be achieved with X". How is this invalid? You are again answering with insults (obsessive fervour) instead of arguments.
Yep.
Both sides are going to need the widget set the application was compiled against. So minor versions will generally be fine but full version numbers you'll need both.
That is a deal breaker right here. How can this ever work? I use ssh to connect to three/four major different institutions each with different departments with computers maintained by different teams. You want the world so sync there software to a single version for every toolkit? Get real. (you are talking about vapourware anyway, because all this does currently not exist on the Wayland side).
How? The X protocol limits what can be sent and what sorts of queries can be used.
You can define extensions and this has been done in the past. X evolved a lot in this way. So in what sense does X limit what sorts of queries can be used?
It limits things like traffic shaping.
How?
There is no way for an X11 app to do a simple request like "do you want me to generate a virtual PDF and send that to you, or do you want the low level print stream to forward to a local printer and if so what format do you want the stream in?"
This is funny. X has been criticized for having things like having an extension for printing. Ofcourse, you could have an extension which negotiates with the client on how a document should be sent to a printer.
No they want to create several. One per widget set. So Qt/KDE would have one, GTK/Gnome would have one. Then there likely would be others like Enlightenment / EWL. Each protocol is going to be smart about respective applications.
So I need to have every toolkit installed everywhere? (and the same version?)
Also, why can toolkits not be smart using a very generic protocol such as X?
Can an application write directly to the graphics buffer or not? If yes you get performance and no network transparency. If no you get network transparency but take a performance hit.
If with graphics buffer you mean a buffer in the server, X had shared memory extenion as an optimization. So yes, you can have both: You use shared memory on local clients and push it ver the network for remote clients. If you mean a buffer on the graphics card, i.e. direct rendering, then X has this is as an optimization for local clients as well. But yes, direct rendering on X was messy, but it seems it gets fixed on X with DRI3 in basically the same way as Wayland also does it.
You aren't getting good efficiency.
Efficiency in terms of what? In terms of volume? Why would this be more with ssh?
Good performance is a result of just using a ton of resources. Lots of problems go away if you throw enough hardware at them. SSH will fall apart very quickly if you start not giving it enough resources. More robust protocols will be able to shape traffic more effectively. Try it by limiting traffic on a VM.
I don't see why: Could you give a technical why this should be true with ssh as a transport. Maybe you are thinking about general stream based transports (e.g. TCP) and UDP might be more efficient? As far as I know RDP uses also TCP as a transport layer. But anyway, tunneling through ssh solves so many practical problems that any other method wlll basically also have to support this even if it is less efficient. Or, no matter how efficient, if it can use ssh as a tunnel it is not nearly as useful.
Wayland is not supposed to be only a backend for X.
So you admit Wayland is more flexible and therefore superior software and you still cringe to the obsolete x11 windowing system?
No. What makes you think this?
The other thing which I really love about Wayland is how friendly its fanboys are ;-)
Implying that i am a fanboy? I write software using Xlib, I understand it's limitation. I also see that your arguments against Wayland make no sense. Adding both make me think Wayland might not be so bad since only idiots seem to hate it with a passion. I intent to look into it when it's packaged in Debian.
Well, you are one acting like a child by insulting people ("shut up", "idiots"") instead of having a discussion. I also don't hate Wayland, I just point out that it breaks compatibility and has no network transparency while having no advantage which could not also be achieved with X. As such I think it would be bad for the Linux community if distributions switch to it by default.
Wayland fanboys...
With X11 you need an X-protocol speaking Xserver on the server side and and X-protocol speaking client on the client side (this could use xlib or xcb or something else). The point is that this protocol has been a standard.
I will suggest looking into Xpra. I'm personally wary of RDP as the specific solution unless it deviates from MS design significantly, but Xpra at least seems to me a proof point that the 'ssh -X' way is no longer the only way.
I know Xpra, it is nice, although I don't need it. But I don't get your point, it uses 'ssh -X'.
Xpra acheives everything I like about ssh -X, but it performs way better and sessions are not hopelessly broken if the connection is lost. It manages to acheive this by sitting between X server and clients as the window manager/compositor rather than actually using the X protocol to acheive it.
But Xpra speaks X on both sides! It only demonstrates that this can be achieved with X - without inventing a new network protocol. In fact, support for reconnecting (moving to another display) could added to clients (and some can do it). Sadly, toolkit developers have other priorities.
Of course I'm not convinced there is such a dire need to replace X at all, but at least I'm open to the possibility that there is a nice and clean mechanism to add X level network transparency by way of the compositor/window manager rather than the relationship between applications and the display server.
The point is: There is no need to invent a new incompatible protocol to do all this. It could be done in a compatible way. I see considerable harm to Linux by breaking compatibility without a good reason.
They are talking about RDP like design not RDP itself. RDP is designed for Windows. Wayland's RDP is going to be designed for Wayland.
They want to create another incompatible protocol?
You could achieve everything Wayland does also by extending X without breaking compatibility.
No you can't. Either applications and graphics are shared or they aren't. There are real tradeoffs of one vs. the other. You can't achieve everything, you have to pick.
I don't see what you mean by applications and graphics are shared? Wayland also separates into a server and clients which communicate with a similar protocol as X. Compositing manger and window manager seem to be merged in Wayland. You could also do this with X if you wanted to. Overall, Wayland is very similar in design to X, but incompatible, without compatibility, and without network transparency. And let me quote from the Wayland FAQ "It's entirely possible to incorporate the buffer exchange and update models that Wayland is built on into X."
X over WAN. You use it over ssh or ipsec. Then there is no security problem.
SSH doesn't know what's going on inside X and the network can't see what's going on inside the ssh session. Which means you get worst possible network performance if you use SSH.
I was replying to your point that there is a security problem: There is not.
On the assumption that you are right and ssh is not optimal for performance, you could use ipsec. This has exactly nothing to do with X as a network protocol. But I have very good performance with 'ssh -X' from home to work so it is working for me and it is very simple.
I hope I will have X for years. But I fear that 1) they force Wayland down on us via a default upgrade path like other recent GUI breakage and 2) they UNIX ecosystem will be harmed in irreparable way because they break backwards and forwards compatibility.
This is even worse. So you need to have every toolkit installed on both sides to make it work? Also you are missing my point. Upgrade GTK from one version to another, does it still work? This is only possible with some standardization. So you even want to re-invent X multiple times in in-compatible ways.
Also, X is a very flexible protocol. Toolkits could already apply deep knowledge if they wanted to and if X is missing something on the server side, this could be added as an extension in a backwards compatible way.
You always have a client and a server if you want to have a windows system, including wayland. An no, X does not emulate a freaking network with high latency on local systems. On local clients, it sends messages over a UNIX domain sockets just like Wayland. So no, there is no difference here - Wayland has basically the same design.
The other stuff you are talking about is direct rendering. Yes, direct rendering on X has been a mess. It is an optimization for local clients which want to have direct access to the graphics hardware. A usual desktop does not need it at all. But yes, better DRI would be nice, and Wayland provides this - but exactly the same can also be achieved by changing the DRI in X. The only thing which speaks for Wayland is that you could get rid some of the old obsolete code in X. But this is only true if you don't want backwards compatibility. In that case, you have to maintain that code anyway, and the overall design gets more complex - instead of simpler.
Migrating X clients. This is not a limitation of X. Some X clients can do it (see libdisplaymigration from the GPE palm desktop environment) and you could add it to others with a LD_PRELOAD hack. I always wondered why the toolkits did not add it. It would be a really useful feature. Much more useful than wobbling windows or all the other crap we got.
And everytime you upgrade the toolkit on one end it breaks? You need a standardized protocol which has a stable core and is also flexible and can be extended in the future.Then you have reinvented X.
I don't care if the X server is monolithic or not. But this is not what the discussion is about. Wayland is not supposed to be only a backend for X.
The other thing which I really love about Wayland is how friendly its fanboys are ;-)
Well, last time I tried to connect to a Windows machine using RDP the client (actually all I tried which I think were all distributed with Ubuntu) crashed because of some unsupported authentication mode or something. Previously, I had other kinds of problems. Maybe the situation is better on Windows. But before threatening to replace X with RDP, I think we should have at least one RDP client which works well.
And anyway, RDP is not an argument for Wayland anyway, because you can use it with X as well - if you like it. This is in general the main problem I have with Wayland: There are NO real advantages - except getting rid of some old code, but only if you break compatibility (otherwise, it simply lives elsewhere). You could achieve everything Wayland does also by extending X without breaking compatibility.
And compatibility goes both ways. Wayland application will not work on X. This is bad. It breaks the ecosytem for no good reason. But also compatibility with X applications will suffer from being an optional compatibility hack. The Jolla phone already ships without X. Another incompatible system!
Easyness. You are talking about performance instead. I know that X can suck when you have low latency connection - but this depends on the application. This is not really a fundamental problem of the X protocol and could be fixed by not using synchronous requests with Xlib.
X over WAN. You use it over ssh or ipsec. Then there is no security problem.
Finally, I am not saying you should not use Wayland if it is better for you. But I am told that I will have to stop using X in the near future while I think it is better for me. You see the difference? I don't care what you use. But I don't want to be switched over by default with my next upgrade. If Wayland is better, offer it as an alternative which people can switch to if they want to try it. If nobody uses X anymore because everybody voted for Wayland by switching, then you can make it the default. So please distributions, freedesktop, gnome and KDE people, please stop breaking my GUI by forcing random changes onto me with every upgrade. This is the Microsoft way - not the free software way.