A "hostile takeover" merely means that non-owners (the management) are opposed to the owners (shareholders) choosing to sell.
A "hostile takeover" merely means that non-owners (the management) are opposed to the owners (shareholders) choosing to sell.
The WOC folks are attempting to use force
If someone offers you a pile of money for your home, and you decide to sell it, it's wild ideological nonsense to say they're taking your home by force.
Since you are such a rational individual and by no way superstitious, you should have no fear to do the following: reply to this post by stating clearly that you hereby sell your soul to Satan for the price of a bag of Cheetos. If you have balls you will also include in this deal the souls of everyone in your family.
Sure, but first you have to let me take your photograph, to prove that you're not afraid that it's going to steal your soul.
It would be cool if we could track the trackers, and post their location on maps in real time; showing where they troll for cars, where they park at night, what donut stores they frequent. After all, the license plate trackers are plainly visible, anybody could see them and remember where and and when they did.
The sensor uses an ultra-low-power receiver to extract and classify gesture information from wireless transmissions around us.
I live in a Faraday cage, you insensitive clod!
I approve of the name AllSee... well... except that they should drop the stupid CamalCase on the 'S'.... and the two l's might be a bit redundant.
I've got some experience sorting huge stacks of pages. You basically want to maximize the work done per trivial-human-step. If you stick with some algorithm based on binary-comparisons you're missing out on some of the work a brain can do essentially for free.
If you're sorting based on a number, it's a pretty quick easy step to drop the current paper in one of ten piles. If you're sorting by alphabetical then you can do one pass 26 piles (bulky but workable) or two pass (first pass A-F, G-M, N-S, T-Z, second pass sort into individual letters). This provides you with more than one bit-comparison of sorting per action. If you're sorting by date then year, month, first-digit-day, second-digit-day make excellent radix values.
Merge sort isn't bad, but it's probably less efficient. If you work with two-stack merge you're only getting one bit of work per step. If you work with more than two stacks you have to scan the tops of the stacks to figure out which page to pick up. Contrast this with radix sort - it's quicker/easier to look at one page and drop it in one of N piles than it is to scan N piles to find which one to pick up.
I see a lot of people mentioning bubble sort and related sorts, but I doubt those people ever had to deal with a few hundred pages. Those sorts are O(N^2), inherently worse. And shuffling the order of pages in a stack is a much messier and slower physical operation than simply dropping pages on the top of stack.
All the other sorting algorithms I can think of seem to suffer from smaller work per step and/or messy physical manipulation. I'm open to other suggestions, but Radix sort seems to be best suited to human work. I had great success with it.
Thank you for the additional details. You are right -- I meant to make it clear that the Wayland design was thought up by people with some serious experience of the internals and limitations of X, and not a competing team of newcomers, as appears to be assumed all too often. But yes, things aren't as simple as I made them look and there is only a partial overlap between the Wayland devs and the Xorgs devs. Thank you for the correction.
I also agree that Wayland is largely about canning the legacy in order to make current and future needs easier to tackle.
I don't agree with your opinion of the move as a technical choice, though, for three reasons.
1/ Taking X out of the rendering loop does not mean dropping X altogether. It just means that future X servers, when and where they are still needed, will run on top of Wayland. It does deprecate X as the default API, yes. But that's not remotely the same as breaking compatibility.
2/ The comments that Daniel Stone (core Xorg and Wayland dev) made in that oft linked video aren't in agreement with the idea that everything Wayland does can be done on top of X, let alone done well. In his talk, DS mentions e.g. issues with input management when one window wants to grab every input that can't be solved in X.
3/ As a more general philosophical principle, the world moves and everything changes. Everything has a shelf life, up to the universe itself, and there is a point where resisting change for the sake of keeping past things going becomes harmful. And this is the actual reason I've been so active in this thread. Not just because I've got a pretty good hunch that once the dust settles Wayland will largely work better than X. But because I think that we, Slashdotters, Linux users, geeks and nerds, are becoming fearful of change, and that's not a good thing. This, here, is an entire new toy and it opens entire new possibilities! It may break shit and it may be awesome and it will probably be a bit of both. Let's freaking check out the code and play with it! Is this not exactly what we should be about?
Have a safe flight, and thank you for the constructive reply!
> Nobody uses Weston so the fact it has RDP support is dick all use to anyone using GNOME or KDE.
Ding ding ding. This, here, is what I think is the main problem with the Wayland ecosystem as it currently exists.
As things currently stand, the Wayland protocol is designed to give compositors a lot of flexibility in what kind of buffers they support, with what capabilities.
The drawback is fragmentation.
So okay, the Unix world at large is not a newcomer to fragmentation issues. But it's still a problem that will have to be addressed.
As I said in another comment, I think that things will probably converge on the common ground of either a de facto standard compositor, or a set of common libraries. Wayland itself will probably ship with a generic, non-optimized implementation for common capabilities like remoting.
But until then, it is an issue, and it would be dishonest not to acknowledge it.
> It will, however suck just as hard as all the other pixel-scrapers.
You are doing the same thing again.
You are asserting, without proof, that Wayland remoting will necessarily have to work as a pixel scrapper.
Wayland is designed to be extensible with regards to supported buffer types. For instance, YUV video buffers were merged into the reference compositor at some point in 2012.
And remoting specific buffer types can be done vastly more efficiently than with a generic pixel scrapper.
For instance, in case of a video buffer, the content can be streamed from the remote app to the local YUV buffer as a lossy video stream without impacting the quality of the other, non-video buffers of the application. (In fact, I think I remember something to that extent being demonstrated somewhere, although I can't find the link, so don't quote me on this.)
Meanwhile, because Xorg's current rendering extensions are not network-transparent, remoting X applications that use those extensions (which will be most of them, these days) does already boil down to filling generic pixel buffers and pushing them down the wire, which works with the approximate efficiency of... a pixel scrapper.
A Wayland stack should therefore be no worse than a current Xorg stack in most cases, and can theoretically be made to work vastly better. (I don't, however, think we are there yet. See below.)
If you're using only pure-X11 apps, though, stick with Xorg for the time being. At least until the Wayland stack supports X buffers sufficiently seamlessly.
> This leads old X11 users to believe they are either liars or incompetent (and hence the lack of trust) because having experienced them all over many years, I know for a fact it is a long way from the worst.
Only if you are willing to make the mental jump of generalizing the one data point of your own limited experience to the entire world and all the use cases that the Xorg developers have to contend with.
If you're gonna give that much weight to single data points, well, I'm afraid that my own long experience of X11, which has most recently involved telecommuting over a VPN and having to use tools like x11vnc and xpra because Xorg remoting on its own works too poorly, neutralizes your own single data point, and we're back to square one.
Unless, of course, you are the sort of person who thinks that their own personal experience constitutes the One Overriding Truth, in which case I don't think there is anything whatsoever to be gained for either of us in this discussion.
> The remote windowing is built into the compositor/windowmanager? I really, really hope someone is making a more sensible architecture than that out there
You appear to think yourself an authority on sensible architectures, so I would suggest you prove it with some actual design and implementation. Otherwise, I hope you will forgive me if I don't trust you nearly as much as I do the guys who are doing the actual work based on actual experience with actual issues.
> otherwise we're going to wind up with a lot of deficient compositors or a lot of duplicated code.
While it could be argued that the many composers/WMs on X already constitutes a lot of duplicated code, I DO agree that the Wayland stack is probably going to be somewhat fragmented for a while, at least until the dust settles.
In practice, I suspect Wayland stacks will end up converging over a shared common ground: probably one display server/composer will emerge as the de facto standard, like Xorg has become the de facto standard of X11 display servers; or Weston itself will evolve into a set of libraries that display servers/composers will be built upon.
But this is only a possible future, and until then, I do think that fragmentation and mismatched composer capabilities is the one big issue with the Wayland budding ecosystem.
Time will tell how big an issue it turns out to be in practice, though.
> The nice thing about X, you see is that it all just works like magic.
I think the entire point is, it's a lot of work for the Xorg developers to make it appear to work 'like magic'. And they'd rather achieve the same result in much saner ways. I don't think I am qualified to claim I know better than them in this, and frankly, you have not convinced me that you are either.
Hi! I would have liked to thank you for taking the time to reply, but I find it difficult to do sincerely, because your comment adds nothing to the discussion, and even detracts from it.
You appear to be trying to imply, with some aggressiveness, that Wayland precludes remoting.
You could have expressed this concern as an interrogation, and I would gladly have tried to share what I understand about the topic.
Instead, no, a bold, unsubstantiated, sarcastic claim with no room for discussion. This is exactly what I meant about the peanut gallery.
Likewise, the fact you refer to the issues the Xorg developers themselves -- you are aware that they are who you refer to as 'the Wayland folks', right? -- have claimed to have with X as 'FUD' makes you look like someone who dismisses contrary opinions instead of addressing them. That really doesn't help the discussion either.
Unless you do, in fact, know better than the Xorg developers themselves. In which case I'm sure you'll step forward to take over the maintenance of Xorg. Won't you?
As to your implied claim, I addressed it in my reply to Uecker below.
Hi! Thank you for taking the time to reply.
I don't personally know the X protocol well enough to comment either way; I can only report on the opinion professed by the X developers themselves.
Here is what I understand are the answers to the points you raise. You'll probably want to check out the talks by Daniel Stone (core Xorg developer) that have been linked elsewhere in the thread, in case I missed something.
Essentially, their opinion is that the X protocol is unsuited to what computers do nowadays. From what I understand, the only task that X11 still performs in current graphic stacks is IPC for the actual rendering extensions, and sadly, IPC is something it's very poor at.
Core X11 is network-transparent by design, but rendering is done through non-core, non-network transparent extensions nowadays. This appears to be a common misunderstanding about the meaning of network-transparent; remote display of application does in fact not require network-transparency because transparency means a lot more than just "remote capable". And Wayland as a protocol is already as remote capable as Xorg because Xorg was already filling buffers remotely and feeding that into SSH connections.
So if you want network-transparency, you'll have to disable all those rendering extensions in your Xorg configuration. But, correct me if I'm wrong, I believe what you really want, is to fire up apps remotely and have them display locally, right? And this has already been implemented in the reference Wayland compositor.
Until then, you will probably not miss the loss of network-transparency because you already lost it in current Xorg servers. I think that this, there, is the number one misunderstanding about both Xorg and Wayland.
You are correct about a window system being more than just about sharing buffers. All the things you mention are being redesigned as part of Wayland with the purpose of fixing issues that the X developers claim were unsolvable with X. (Don't take my word for it, though. Check out those talks.)
So in essence, the X developers think that Wayland stacks will be better than Xorg stacks at everything that Xorg does. Including remoting.
I do actually have one reservation about that general claim, and interestingly, it's one that I haven't seen come up from the aforementioned peanut gallery. But time will tell.
But until then, the X developers think that designing a new API from scratch is more straightforward than monkeypatching the old one into doing the same things. If you sincerely think they are wrong, maybe you'll want to step forward and take over the maintenance of Xorg? I'm sure some people out there would be grateful.
I, for one, am going to trust that they know what they are doing, but you may feel otherwise about that, and that's fine. There's just a "put up or shut up" line there that people who share your opinion seem unwilling to cross, and I think that's worth pointing out.
The story so far in a nutshell:
The Xorg developers got tired of spending their time working around the way X was designed in 1980 (which made sense at the time) to try and make it fit 2010 workloads and hardware.
They started to think about how to do the stuff that actually needs doing in an efficient manner, while removing the roadblocks they currently have to contend with.
Turns out that when you take what Xorg actually does nowadays, streamline the fuck out of it, and take away all the needless obstacles, you end up with a pretty straightforward buffer sharing protocol. They called it Wayland and started to work on an implementation.
And then the countless people in the peanut gallery who obviously know X much better than the X developers beheld the notion and started giving... loud feedback, shall we say. Without ever stepping forward to take over the maintenance of Xorg, mind you.
TL;DR: Xorg developers make what they concluded is the soundest technical choice. People on the Internet lose their shit. Business as usual.
Actually there is an extensive section on Privacy Considerations, but it has been deemed classified under U.S. National Security.
What is research but a blind date with knowledge? -- Will Harvey