Restaurants started using larger containers to... trick customers into buying more than they want or need.
Methinks your theory has a hole. If I'm getting free refills, then the restaurant doesn't benefit from me drinking more. They benefit from me drinking less (i.e. same revenue at lower cost to them). Even if they charged for refills, they would make more money with smaller cups as that means more refills (i.e. more revenue at the same cost to them).
(An important factor here is that two 8oz cups of soda are prices to cost more than one 16oz cup.)
Properties that I would not require a slow function to have includes collision resistance
Unless you are very careful about how you define slowness, I think collision resistance (or something like it) might actually be important. For example, suppose 90% of all inputs result in the same output but to determine whether a particular value hashes to that common value might still require a lot of computation. Then if I want to crack a leaked password table, I compute a rainbow table assuming the slow function is just the constant function that always produces that common value. It is an invalid assumption, but statistically it will break a number of passwords.
In any case, your ideas are intriguing to me and I look forward to a peer-reviewed paper with full mathematical proofs to see whether they actually work.
You are wrong and never should have been moded "Insightful".
Similarly, some observers would see you as moving backwards, but that's just because you're moving faster than the photons you're emitting
Even once you cancel out the effects of traveling faster than the photons you're emitting, you will still be seen to be traveling backwards in time by some observers.
Lookup "relativity of simultaneity". Using that you can send a message back in time to back to the original person even before that person sent it. Or instead of a message, you could just send yourself and thus get "true" time travel.
It affects causality because in SR (special relativity) all velocity, both sub- and super-luminal(*), effect event ordering. Once you get to super-luminal speeds, event ordering is affected enough to break causality. This has nothing to do with "apparent" time travel. In fact, for the purposes of discussion, let's assume all observations have already had "apparent" time travel canceled out.
To understand this, consider that in SR (as well as in Newtonian mechanics), non-accelerating movement is the same as being stationary. In your local reference frame, you are at the origin and the time axis lies along a line in space-time that you call "here". If you and I meet, but traveling at different velocities, then our here-lines will be skew relative to each other. At the current instant we might be at that same point in space, but in a moment we will be separated by some distance. We each follow our own here-line and each is equally valid as a non-accelerating reference frame.
One of the results of SR is that not only can you have different "here" lines, but you can have different "now" lines(**). This is to say, that when you are traveling at velocity, the set of events that occur "now" is different than for someone traveling at a different velocity... even when you cancel out the time it takes for the information to get to you. Velocity bends both the space and time axises of your local reference frame.
Note that because you are always at the origin of your local reference frame, the effect of skewing the axises is quite small nearby but it grows larger for events further away. For example, the ordering of two events occurring several light-years away in opposite directions can be different by several hours for you and someone jogging quickly past you.
Suppose an event is in the past for the jogger and in the future for you, and we have super-luminal communication. Then someone at that event could tell the jogger about what happened (because it is the in joggers past), the jogger could tell you (because you are right next to each other in the same present), and you could tell the original person about it before the event happened (because it is in your future). As long as nothing is faster than light, there is no problem as the amount that event orderings can get skewed is bounded by the speed of light, and information also can't travel faster than light in order to give you a causality cycle. However, once you get super-luminal travel, we can set up this cycle.
Lookup "relativity of simultaneity" for more information.
(*) Note that "speed of light" doesn't mean the "speed" of light. It really means the conversion constant between space and time units. Light happens to go at that speed, but if you figure out a way to make light go slower than you without you going faster than that conversion constant, then that doesn't count as super-luminal.
(**) A now-line is really a 3-dimentional slice of 4-dimentional space-time, so it is not really a line, but I'm calling it that because it is easier to visualize as a 1D line in a 2D space-time.
However, the "absolute" time at place B is exactly the same as at place A
Special relativity says this statement is false. It's call the relativity of simultaneity and has nothing to do with the amount of time necessary for light to travel from A to B (i.e., it holds even once you cancel out that effect from the observations). In special relativity, speed doesn't actually compress or expand time, it applies a skew transform to the space and time axises of your local reference frame.
What you seem to mean by "network transparency" is not full network transparency but rather "the ability to run applications remotely" i.e. on a per application basis being able to run applications on your native desktop and get sane (but not necessarily great) performance.
Agreed, though I'll qualify that I want it pervasively (e.g. like with X11 where it is possible but very rare for an app to break network transparency). Having only 95% of apps work remotely is almost worse than having 0% of apps work remotely because with 95% you come to depend upon it only to get bit by the one app that you didn't foresee not working across the network. It needs to be a very rare event to find an app that doesn't work across the network.
My main concern is that the way the Wayland development process is being run will make it hard for their to be a remoting solution that is both pervasive and good. (VNC is pervasive, but it is not good at integrating remote apps with the local desktop.)
That Wayland does intend to support, though indirectly. They want that supported with a mechanism similar to Microsoft's RDB. So for example at the Gnome level or the KDE level that sort of remote application management would exist. And similar to DBUS the hope then would be a cross Unix mechanism.
OK, let's dissect this. If Gnome and KDE independently implement their own network layer, then chances are they won't inter-operate. Having something like DBUS would be better, but then we need to ensure the use of this DBUS-like layer is also pervasive. If it were integrated into Wayland or if from the start Wayland had this extra layer on top that all (minus epsilon) apps had to use it, then we would be OK. However, the Wayland developer's seem to be heading in a direction that makes that unlikely (even if only because they are ignoring the issue).
So they are 100% against network transparency, they aren't opposed to remote applications.
Last I looked into this, the plans for remote applications were along the lines of "well, maybe someone will come along and do it for us, but we're not going to do it ourselves, and are certainly not going consider it in our design choices". Has that changed? If not, then it will be hard to get a pervasive remoting solution (e.g. market timing, temptation for developers to bypass the networking layer and write directly to Wayland, chance of the Wayland developers inadvertently making it unnessisarily hard to implement such a solution, etc.).
I can understand limiting the scope of your project, but remotability needs to be given just as much consideration as things like input methods, clipboards, window managers, etc. Sure, they aren't part of the core rendering pipeline, but you can't just ignore them and expect to be able to bolt them on later. You need to at least have some reasonable plans for them so they can inform your design process. It's even better to have implementations so you can find unexpected complications. (OK, well, I guess X11 did bolt a few of those things on later, but that's not an example to emulate.) In fact, remotability is probably one of the least easy to bolt on after the fact. Maybe the developers have changed their attitudes (and I would love to see evidence of that), but last I checked they were rather blithly ignoring it.
Most of the anti-Wayland people believe Wayland will be terrible and this won't happen. So it can't be assumed in these debates.
Hmm, I hadn't noticed that, but my perspective is of course different. (Mostly I'm too busy wading through the widespread but ignorant arguments defending Wayland's lack of network transparency (e.g., "just use VNC").) I would actually be very pro-Wayland (it seems to have more support than other X11 replacements), but remotability is a deal breaker for me.
Today for me and for most people (a) and (c) are much more common, so common t
Ok, we agree that having an app support both X11 and Wayland is a bad idea. (I only included it because I wasn't sure what you were suggesting.)
We also agree that having apps implement their own "network transparency" solution is a bad idea.
These two stipulations then mean that every app will have to choose between X11 and Wayland. (This of course brings us back to my original comment.) If scenario (b) never occurs and we stay in scenario (a), then perhaps things are fine. You won't be able to run Quake across the network, but for the most part apps support network transparency. That is fine. Right now, there is a cultural bias against using the framebuffer so only those apps to use it are the ones that really need it. It's conceivable the same could happen where developers avoid using Wayland and use it only when really necessary. However, if Wayland lives up to its promise and is much better and easier to support and maintain than X11, then there will be a strong incentive to move to scenario (b). Not only is having the community continue to support both would a waste of developer resources, but with all the PR that Wayland has been getting, there are plenty of developers (some justified and some not) just waiting to play with the new shiny. This would be a disaster for network transparency.
For those apps that need transparency (which I contend is few or none) they offer to compile to a X11 version.
Apps don't need transparency. Users need transparency. The other day I had to run Firefox remotely in order to deal with an IP based subscription. You wouldn't peg Firefox as an app needing transparency. Or for example, I used to do a lot of work on a cluster machine. The cluster was in a server room upstairs for cooling reasons, and for various reasons the disk wasn't shared for remote access, so development work for that cluster effectively had to be done on the head node of that cluster (the head node acted as a shared multi-user server and also controlled and acted as a gateway to the other nodes which did the actual super computing). Some days that meant using DDD or a PDF viewer. Other days it meant using the GnuPlot GUI or Gimp or even OpenOffice Calc. In none of these cases was it a property of the app that determined whether I wanted to run it across the network. It was a property of the surrounding context and use case. Any app that someone might use to do development or analysis was fair game.
I'm not sure where you stand on the issue of permanently unsolvable performance problems with X11 which impact high performance applications.
I don't have a stand. I've seen people claim they exist, but I've not seen them explained. Thus, I don't have enough data to evaluate that claim for myself.
Finally, I have to call foul on the following:
And again doing this sort of legwork to make sure Gnome 5 supports X11 is something X11 supporters can do (assuming their theory is correct that X11 doesn't hamper functionality).
Network transparency supporters are not necessarily X11 supporters. This isn't X11 vs Wayland. It is network transparency vs not. I would love to see a good alternative for X11 take over (be it Wayland or otherwise), but I still want my network transparency. In light of that, the debate isn't whether X11 hampers functionality. It is whether the network transparency should be widely supported in the Linux GUI ecosystem be that via X11 or something else. (I'd love to say "via Wayland", but the developers seem dead set against it.)
creating X / network transparent version of applications that migrate to Wayland
Either you are suggesting that apps should implement their own "network transparency" or you are suggesting that applications should be linked so they switch between using X and using Wayland depending on what is available. Both these ideas are often suggested by Wayland defenders, but both are bad ideas.
Expecting applications to implement their own network transparency is a bad idea. If you put network code in the app, then the app has to be installed on both ends (this means I can't run most Linux apps from a Windows "client" (i.e. what X11 calls a server)), most apps won't implement it (Murphy's Law will ensure the app you actually need doesn't implement it), apps that do implement it will do so poorly (insecure, poorly defined protocols etc). It is far better to implement it once in the input/graphics stack, then to expect every app to implement it's own.
I could go into why expecting every application to support both X and Wayland is a bad idea, but I hope it is self evident. Remember this wouldn't be some transitional state; you would have to make every app keep supporting X just to get the network transparency.
I suspect most supporters of network transparency could care less if games and video editing software went local only.
I agree that I don't care about those... until the day that I do. Suppose I need to test the installation of some game or video editing software.;-P Or for example, one day I had office hours downstairs, but needed to run a program off my machine upstairs (yes, actually happened and X worked like a dream). There is no reason to believe that the monitoring-installation vs games-video-editing division or any other division that you can think of will be the correct one for all use cases. Such a division makes a policy (i.e. functionality) assumption about user behaviors that shouldn't be made(*). I'd rather have the mechanism for the user to do either.
It's a shame really. I would like to see a good replacement for X, but I live on the network. I would like to believe the people behind Wayland are smart enough to incorporate network transparency, but they seem to rather stubborn in omitting it(**).
(*) Aside from the problem of meaning the community now has to permanently support two graphics stacks (X and Wayland).
(**) No, VNC isn't good enough. No, having the app implement the network doesn't work as that requires having the app installed locally and not all apps will implement a network (which gets us back to the start of this post). No, back patching network transparency into the protocol "later" isn't a good way to go about design. No, hoping that someone else solves the problem isn't a good design philosophy either.
The original code doesn't have any tail calls(*) because after the call to manageWorkers returns, there is the rest of the iterations through the while-loop to be done. Thus a correct compiler should *not* tail-call optimize this code. If the original code had been "if (worker)" instead of "while (worker)", then you could tail-call optimize the code. (Source: I write compilers for a living.)
(*) "Tail-recursion" is just a special case of tail calls. A tail call doesn't have to be recursive to be worth optimizing. Though the two optimizations can be implemented differently from each other, everything I've said is about both.
The legal principal you are describing is called "Sweat of the Brow". The supreme court rejected that doctrine in "Feist v. Rural". (Though that was a copyright case not a patent case, the same reasoning applies.)
It's the unintuitive ways in which it's taught... that is the problem
Lockhart put this quite elegantly in his A Mathematician's Lament. Treating math as a rote subject (as it is now) is the moral equivalent teaching art as paint by numbers.
Left and right don't actually exist. They are a tool of the political powers to keep people in the us versus them / my team versus their team mentality.
The political spectrum is a multidimentional hyperspace, and collapsing it to one or even two or three dimentions leads to contradictions and naive thinking. In the US, being pro-weed is considered left, but so is being anti-tabaco. Being against abortion is considered right but so is being pro-death penalty. This is a very inconsistent way of categorizing beliefs and makes many mutually consistent beliefs look like they are in opposition.
You're describing the hidden variable theory which was disproved by Bell's Theorem. A subtle point of the Chopenhagin Interpretation that you omitted is that while the waveforms are non-deterministic, measurements cause a collapse of the waveform that is non-deterministic and thus the universe really is non-deterministic. It's not just an artifact of the math.
they may take away the capability to disable it entirely
They already are taking it away on ARM based systems. "On an ARM system, it is forbidden to enable Custom Mode.... Disabling Secure MUST NOT be possible on ARM systems" (page 122 of Windows Hardware Certification Requirements)
Ubuntu plans to have a loader image that is signed by Microsoft's WinQual key (which chains to efilinux which then chains to Grub2 (this is madness) which then loads unsigned kernels). They mention it only for booting the install CD, but I suspect an enterprising malware author will figure out a way to use this path.
If there is any break in the chain, from boot to application, the remote attestation will fail. That is what secure boot gets you.
Then there is no reason to prevent booting unsigned software. This is what I'm objecting to. Let the unsigned software boot. If it fails remote attestation later, then fine. But locking out unsigned software from even booting buys nothing(*).
(*) Other, than a means for Microsoft to scare users off from trying other operating systems.
If you have installed a (signed) boot loader that does not verify signature of the kernel, you are open to some malware being installed. That is of your own doing.
But you don't have to install a signed boot loader that does not verify signature of the kernel, to be open to some malware being installed. Malware can install a signed boot loader that does not verify signature of the kernel. (All large software has bugs, thus all kernels have zero-days. SecureBoot is about preventing the malware from burrowing deeper into the system, not about preventing malware from getting on the system in the first place.)
And those things can check to see that the chain before them is unbroken.
OK, so an app generates a random number and asks the OS to encrypt it with the private key stored in the TPM but the TPM will only encrypt the number with that key if the hash of the memory from the kernel matches a specified list. Finally, the application decrypts the result provided by the OS and compares the result with the original random number. Is something like that what you mean? I can believe that that would work (if we assume that malware authors don't have time to patch every app and can't crack the TPM), but that process doesn't require or involve the bootloader checking the signature of the kernel or the boot process checking the signature of the bootloader. So why again should we be locking down the bootloader and the boot hardware to only load signed kernels and bootloaders?
To review: the lower levels can't stop a break in the upper levels of the chain (because the malware can install a signed bootloader that will load an unsigned kernel), and the way that upper levels catch a break in the lower levels of the chain doesn't need the lower levels to only load signed versions of the upper levels. It sounds to me like SecureBoot doesn't actually provide any protection.
So the malware just patches the part of the kernel doing that check to not do that check. The Windows kernel can't know who loaded it because it can't know that its own process of checking who loaded it hasn't already been compromised. This is basically Descartes's Evil Demon. There is nothing you can do to detect the demon if the demon can manipulate your reasoning ability (by making your always conclude the demon doesn't exist) or memory (by making you falsely remember concluding the demon doesn't exist).
Slashdot Mirror
Restaurants started using larger containers to ... trick customers into buying more than they want or need.
Methinks your theory has a hole. If I'm getting free refills, then the restaurant doesn't benefit from me drinking more. They benefit from me drinking less (i.e. same revenue at lower cost to them). Even if they charged for refills, they would make more money with smaller cups as that means more refills (i.e. more revenue at the same cost to them).
(An important factor here is that two 8oz cups of soda are prices to cost more than one 16oz cup.)
80cm?
You're right, 80cm might be a bit small for Jefferies tubes.
Properties that I would not require a slow function to have includes collision resistance
Unless you are very careful about how you define slowness, I think collision resistance (or something like it) might actually be important. For example, suppose 90% of all inputs result in the same output but to determine whether a particular value hashes to that common value might still require a lot of computation. Then if I want to crack a leaked password table, I compute a rainbow table assuming the slow function is just the constant function that always produces that common value. It is an invalid assumption, but statistically it will break a number of passwords.
In any case, your ideas are intriguing to me and I look forward to a peer-reviewed paper with full mathematical proofs to see whether they actually work.
You can't go backwards in time using FTL.
You are wrong and never should have been moded "Insightful".
Similarly, some observers would see you as moving backwards, but that's just because you're moving faster than the photons you're emitting
Even once you cancel out the effects of traveling faster than the photons you're emitting, you will still be seen to be traveling backwards in time by some observers.
Lookup "relativity of simultaneity". Using that you can send a message back in time to back to the original person even before that person sent it. Or instead of a message, you could just send yourself and thus get "true" time travel.
It affects causality because in SR (special relativity) all velocity, both sub- and super-luminal(*), effect event ordering. Once you get to super-luminal speeds, event ordering is affected enough to break causality. This has nothing to do with "apparent" time travel. In fact, for the purposes of discussion, let's assume all observations have already had "apparent" time travel canceled out.
To understand this, consider that in SR (as well as in Newtonian mechanics), non-accelerating movement is the same as being stationary. In your local reference frame, you are at the origin and the time axis lies along a line in space-time that you call "here". If you and I meet, but traveling at different velocities, then our here-lines will be skew relative to each other. At the current instant we might be at that same point in space, but in a moment we will be separated by some distance. We each follow our own here-line and each is equally valid as a non-accelerating reference frame.
One of the results of SR is that not only can you have different "here" lines, but you can have different "now" lines(**). This is to say, that when you are traveling at velocity, the set of events that occur "now" is different than for someone traveling at a different velocity ... even when you cancel out the time it takes for the information to get to you. Velocity bends both the space and time axises of your local reference frame.
Note that because you are always at the origin of your local reference frame, the effect of skewing the axises is quite small nearby but it grows larger for events further away. For example, the ordering of two events occurring several light-years away in opposite directions can be different by several hours for you and someone jogging quickly past you.
Suppose an event is in the past for the jogger and in the future for you, and we have super-luminal communication. Then someone at that event could tell the jogger about what happened (because it is the in joggers past), the jogger could tell you (because you are right next to each other in the same present), and you could tell the original person about it before the event happened (because it is in your future). As long as nothing is faster than light, there is no problem as the amount that event orderings can get skewed is bounded by the speed of light, and information also can't travel faster than light in order to give you a causality cycle. However, once you get super-luminal travel, we can set up this cycle.
Lookup "relativity of simultaneity" for more information.
(*) Note that "speed of light" doesn't mean the "speed" of light. It really means the conversion constant between space and time units. Light happens to go at that speed, but if you figure out a way to make light go slower than you without you going faster than that conversion constant, then that doesn't count as super-luminal.
(**) A now-line is really a 3-dimentional slice of 4-dimentional space-time, so it is not really a line, but I'm calling it that because it is easier to visualize as a 1D line in a 2D space-time.
However, the "absolute" time at place B is exactly the same as at place A
Special relativity says this statement is false. It's call the relativity of simultaneity and has nothing to do with the amount of time necessary for light to travel from A to B (i.e., it holds even once you cancel out that effect from the observations). In special relativity, speed doesn't actually compress or expand time, it applies a skew transform to the space and time axises of your local reference frame.
All I see is a garbled executive "flow chart"
IIRC, the USPTO refuses to accept source code and insists on flow charts, which I agree is quite stupid.
(My info on this might be wrong, so corrections or confirmations are both welcome.)
What you seem to mean by "network transparency" is not full network transparency but rather "the ability to run applications remotely" i.e. on a per application basis being able to run applications on your native desktop and get sane (but not necessarily great) performance.
Agreed, though I'll qualify that I want it pervasively (e.g. like with X11 where it is possible but very rare for an app to break network transparency). Having only 95% of apps work remotely is almost worse than having 0% of apps work remotely because with 95% you come to depend upon it only to get bit by the one app that you didn't foresee not working across the network. It needs to be a very rare event to find an app that doesn't work across the network.
My main concern is that the way the Wayland development process is being run will make it hard for their to be a remoting solution that is both pervasive and good. (VNC is pervasive, but it is not good at integrating remote apps with the local desktop.)
That Wayland does intend to support, though indirectly. They want that supported with a mechanism similar to Microsoft's RDB. So for example at the Gnome level or the KDE level that sort of remote application management would exist. And similar to DBUS the hope then would be a cross Unix mechanism.
OK, let's dissect this. If Gnome and KDE independently implement their own network layer, then chances are they won't inter-operate. Having something like DBUS would be better, but then we need to ensure the use of this DBUS-like layer is also pervasive. If it were integrated into Wayland or if from the start Wayland had this extra layer on top that all (minus epsilon) apps had to use it, then we would be OK. However, the Wayland developer's seem to be heading in a direction that makes that unlikely (even if only because they are ignoring the issue).
So they are 100% against network transparency, they aren't opposed to remote applications.
Last I looked into this, the plans for remote applications were along the lines of "well, maybe someone will come along and do it for us, but we're not going to do it ourselves, and are certainly not going consider it in our design choices". Has that changed? If not, then it will be hard to get a pervasive remoting solution (e.g. market timing, temptation for developers to bypass the networking layer and write directly to Wayland, chance of the Wayland developers inadvertently making it unnessisarily hard to implement such a solution, etc.).
I can understand limiting the scope of your project, but remotability needs to be given just as much consideration as things like input methods, clipboards, window managers, etc. Sure, they aren't part of the core rendering pipeline, but you can't just ignore them and expect to be able to bolt them on later. You need to at least have some reasonable plans for them so they can inform your design process. It's even better to have implementations so you can find unexpected complications. (OK, well, I guess X11 did bolt a few of those things on later, but that's not an example to emulate.) In fact, remotability is probably one of the least easy to bolt on after the fact. Maybe the developers have changed their attitudes (and I would love to see evidence of that), but last I checked they were rather blithly ignoring it.
Most of the anti-Wayland people believe Wayland will be terrible and this won't happen. So it can't be assumed in these debates.
Hmm, I hadn't noticed that, but my perspective is of course different. (Mostly I'm too busy wading through the widespread but ignorant arguments defending Wayland's lack of network transparency (e.g., "just use VNC").) I would actually be very pro-Wayland (it seems to have more support than other X11 replacements), but remotability is a deal breaker for me.
Today for me and for most people (a) and (c) are much more common, so common t
Ok, we agree that having an app support both X11 and Wayland is a bad idea. (I only included it because I wasn't sure what you were suggesting.)
We also agree that having apps implement their own "network transparency" solution is a bad idea.
These two stipulations then mean that every app will have to choose between X11 and Wayland. (This of course brings us back to my original comment.) If scenario (b) never occurs and we stay in scenario (a), then perhaps things are fine. You won't be able to run Quake across the network, but for the most part apps support network transparency. That is fine. Right now, there is a cultural bias against using the framebuffer so only those apps to use it are the ones that really need it. It's conceivable the same could happen where developers avoid using Wayland and use it only when really necessary. However, if Wayland lives up to its promise and is much better and easier to support and maintain than X11, then there will be a strong incentive to move to scenario (b). Not only is having the community continue to support both would a waste of developer resources, but with all the PR that Wayland has been getting, there are plenty of developers (some justified and some not) just waiting to play with the new shiny. This would be a disaster for network transparency.
For those apps that need transparency (which I contend is few or none) they offer to compile to a X11 version.
Apps don't need transparency. Users need transparency. The other day I had to run Firefox remotely in order to deal with an IP based subscription. You wouldn't peg Firefox as an app needing transparency. Or for example, I used to do a lot of work on a cluster machine. The cluster was in a server room upstairs for cooling reasons, and for various reasons the disk wasn't shared for remote access, so development work for that cluster effectively had to be done on the head node of that cluster (the head node acted as a shared multi-user server and also controlled and acted as a gateway to the other nodes which did the actual super computing). Some days that meant using DDD or a PDF viewer. Other days it meant using the GnuPlot GUI or Gimp or even OpenOffice Calc. In none of these cases was it a property of the app that determined whether I wanted to run it across the network. It was a property of the surrounding context and use case. Any app that someone might use to do development or analysis was fair game.
I'm not sure where you stand on the issue of permanently unsolvable performance problems with X11 which impact high performance applications.
I don't have a stand. I've seen people claim they exist, but I've not seen them explained. Thus, I don't have enough data to evaluate that claim for myself.
Finally, I have to call foul on the following:
And again doing this sort of legwork to make sure Gnome 5 supports X11 is something X11 supporters can do (assuming their theory is correct that X11 doesn't hamper functionality).
Network transparency supporters are not necessarily X11 supporters. This isn't X11 vs Wayland. It is network transparency vs not. I would love to see a good alternative for X11 take over (be it Wayland or otherwise), but I still want my network transparency. In light of that, the debate isn't whether X11 hampers functionality. It is whether the network transparency should be widely supported in the Linux GUI ecosystem be that via X11 or something else. (I'd love to say "via Wayland", but the developers seem dead set against it.)
creating X / network transparent version of applications that migrate to Wayland
Either you are suggesting that apps should implement their own "network transparency" or you are suggesting that applications should be linked so they switch between using X and using Wayland depending on what is available. Both these ideas are often suggested by Wayland defenders, but both are bad ideas.
Expecting applications to implement their own network transparency is a bad idea. If you put network code in the app, then the app has to be installed on both ends (this means I can't run most Linux apps from a Windows "client" (i.e. what X11 calls a server)), most apps won't implement it (Murphy's Law will ensure the app you actually need doesn't implement it), apps that do implement it will do so poorly (insecure, poorly defined protocols etc). It is far better to implement it once in the input/graphics stack, then to expect every app to implement it's own.
I could go into why expecting every application to support both X and Wayland is a bad idea, but I hope it is self evident. Remember this wouldn't be some transitional state; you would have to make every app keep supporting X just to get the network transparency.
I suspect most supporters of network transparency could care less if games and video editing software went local only.
I agree that I don't care about those ... until the day that I do. Suppose I need to test the installation of some game or video editing software. ;-P Or for example, one day I had office hours downstairs, but needed to run a program off my machine upstairs (yes, actually happened and X worked like a dream). There is no reason to believe that the monitoring-installation vs games-video-editing division or any other division that you can think of will be the correct one for all use cases. Such a division makes a policy (i.e. functionality) assumption about user behaviors that shouldn't be made(*). I'd rather have the mechanism for the user to do either.
It's a shame really. I would like to see a good replacement for X, but I live on the network. I would like to believe the people behind Wayland are smart enough to incorporate network transparency, but they seem to rather stubborn in omitting it(**).
(*) Aside from the problem of meaning the community now has to permanently support two graphics stacks (X and Wayland).
(**) No, VNC isn't good enough. No, having the app implement the network doesn't work as that requires having the app installed locally and not all apps will implement a network (which gets us back to the start of this post). No, back patching network transparency into the protocol "later" isn't a good way to go about design. No, hoping that someone else solves the problem isn't a good design philosophy either.
If Wayland catches on, there will be no more X11 apps. Everything will be Wayland apps.
The original code doesn't have any tail calls(*) because after the call to manageWorkers returns, there is the rest of the iterations through the while-loop to be done. Thus a correct compiler should *not* tail-call optimize this code. If the original code had been "if (worker)" instead of "while (worker)", then you could tail-call optimize the code. (Source: I write compilers for a living.)
(*) "Tail-recursion" is just a special case of tail calls. A tail call doesn't have to be recursive to be worth optimizing. Though the two optimizations can be implemented differently from each other, everything I've said is about both.
The legal principal you are describing is called "Sweat of the Brow". The supreme court rejected that doctrine in "Feist v. Rural". (Though that was a copyright case not a patent case, the same reasoning applies.)
It's the unintuitive ways in which it's taught ... that is the problem
Lockhart put this quite elegantly in his A Mathematician's Lament. Treating math as a rote subject (as it is now) is the moral equivalent teaching art as paint by numbers.
the number 1 single handed murderer in US history did it with 1 gallon of gasoline and a match.
Forgive my ignorance, but who are you talking about?
Left and right don't actually exist. They are a tool of the political powers to keep people in the us versus them / my team versus their team mentality.
The political spectrum is a multidimentional hyperspace, and collapsing it to one or even two or three dimentions leads to contradictions and naive thinking. In the US, being pro-weed is considered left, but so is being anti-tabaco. Being against abortion is considered right but so is being pro-death penalty. This is a very inconsistent way of categorizing beliefs and makes many mutually consistent beliefs look like they are in opposition.
And don't forget about bicycles, motercycles and scooters. Those won't be automous so you will still need trafic lights for them.
You're describing the hidden variable theory which was disproved by Bell's Theorem. A subtle point of the Chopenhagin Interpretation that you omitted is that while the waveforms are non-deterministic, measurements cause a collapse of the waveform that is non-deterministic and thus the universe really is non-deterministic. It's not just an artifact of the math.
they may take away the capability to disable it entirely
They already are taking it away on ARM based systems. "On an ARM system, it is forbidden to enable Custom Mode. ... Disabling Secure MUST NOT be possible on ARM systems" (page 122 of Windows Hardware Certification Requirements)
That would be so rediculously absurd that I want a citation for it.
Ubuntu plans to have a loader image that is signed by Microsoft's WinQual key (which chains to efilinux which then chains to Grub2 (this is madness) which then loads unsigned kernels). They mention it only for booting the install CD, but I suspect an enterprising malware author will figure out a way to use this path.
If there is any break in the chain, from boot to application, the remote attestation will fail. That is what secure boot gets you.
Then there is no reason to prevent booting unsigned software. This is what I'm objecting to. Let the unsigned software boot. If it fails remote attestation later, then fine. But locking out unsigned software from even booting buys nothing(*).
(*) Other, than a means for Microsoft to scare users off from trying other operating systems.
If you have installed a (signed) boot loader that does not verify signature of the kernel, you are open to some malware being installed. That is of your own doing.
But you don't have to install a signed boot loader that does not verify signature of the kernel, to be open to some malware being installed.
Malware can install a signed boot loader that does not verify signature of the kernel. (All large software has bugs, thus all kernels have zero-days. SecureBoot is about preventing the malware from burrowing deeper into the system, not about preventing malware from getting on the system in the first place.)
And those things can check to see that the chain before them is unbroken.
OK, so an app generates a random number and asks the OS to encrypt it with the private key stored in the TPM but the TPM will only encrypt the number with that key if the hash of the memory from the kernel matches a specified list. Finally, the application decrypts the result provided by the OS and compares the result with the original random number. Is something like that what you mean? I can believe that that would work (if we assume that malware authors don't have time to patch every app and can't crack the TPM), but that process doesn't require or involve the bootloader checking the signature of the kernel or the boot process checking the signature of the bootloader. So why again should we be locking down the bootloader and the boot hardware to only load signed kernels and bootloaders?
To review: the lower levels can't stop a break in the upper levels of the chain (because the malware can install a signed bootloader that will load an unsigned kernel), and the way that upper levels catch a break in the lower levels of the chain doesn't need the lower levels to only load signed versions of the upper levels. It sounds to me like SecureBoot doesn't actually provide any protection.
So the malware just patches the part of the kernel doing that check to not do that check. The Windows kernel can't know who loaded it because it can't know that its own process of checking who loaded it hasn't already been compromised. This is basically Descartes's Evil Demon. There is nothing you can do to detect the demon if the demon can manipulate your reasoning ability (by making your always conclude the demon doesn't exist) or memory (by making you falsely remember concluding the demon doesn't exist).