Interview: Thomas Voß of Mir

Regardless, the answer is "everything is simple when you imagine a single use-case", which as far as I know is what he is doing. I would suggest that people with experience building multi-use-case display servers would know best, those building single-use-case display servers second best, and everybody else is essentially working on guesswork and imagination.

That said, if he wants to go ahead and prove us all wrong by writing a small, elegant display server which fulfils everybody's needs without compromise, I wish him luck and can't wait to start using it :)

I mean, it's a server. It's a singleton process, which many other processes much communicate with. What other widely supported ICP technique do you think is better for this job, and would make it simpler to develop against?

Also he doesn't seem to understand the design goals nor the complexity of what Mir is trying to accomplish. Therefore I don't give it much weight.

Seriously?

I would say that in all the software I have ever written, some part of it sucked. It's actually quite upsetting if I think too hard about it, I wish it wasn't that way. This is mainly because of four reasons (in no particular order):

1. I didn't have time to really finish it

2. I didn't test it thoroughly enough

3. There was some part of the underlying language or framework that I was unaware of that behaves unexpectedly (e.g. the framework encodes output, the int in the language can only handle up to 16384, or you can add a general error catcher, but if you invoke a web method in a particular way, the framework 'helpfully' circumvents the error handler, leading to weird bug that you never hear about)

4. I was using a new language/framework that I didn't know quite how to use. It's not just inexperience, quite often the examples for new frameworks/languages turn out to be bad practices or inefficient ways of doing things in the long run.

Even if you're a good programmer and try and plan ahead, quite often you're writing something you don't quite understand until you actually write it and as you go you make, in hindsight, a couple of poor decisions. It's often a big job to go back and change those poor decisions, and even if you did it might not completely fix the problem. Some remnants of the old design stick around like a bad smell.

And there's also bad design decisions that don't come out until the program is out in the wild, you might have thought the purpose of your wheel was to make bicycles, but in fact only a couple of neckbeards make bicycles, everyone else is making cars out of them and they're completely the wrong design.

And worse, only the neckbeards are on the mailing list so you get a disproportionate amount of feedback from a vocal minority and don't even realise it's not really suitable.

And on top of that, some software suffers from the first mover advantage though it's badly written and then gets almost, but not quite, abandoned, so no-one ever moves to the much better alternatives.

And then all those little warts and mistakes, as you say, propagate.

I have screamed at my screen in rage at how stupid some programmer has been while designing a program that almost does what I want but quite spectacularly (or worse silently) fails at some key part. But they probably tried hard to make it good.

In truth, writing excellent software is still the domain of a very elite few, the rest of us write ok, but very brittle, software.

EDIT: Added reason 4

I'm sure almost everyone here has at some point looked at a task an said 'Oh that's easy, I'll do it in a week!', and then realised that it's a rabbit warren of peculiar instances, customer needs, and unique problems.

It's like people who think Time is easy, but they forgot timezones, and then they write timezones but they forgot half hour timezones, or quarter hour timezones, or daylight savings time, or leap years, or different calendars, or the fact that calendars change over time, over place, that timezones change, are adapted, etc.

Well, then this gentleman should get off his high horse.

It's important to note that there's a big distinction between Wayland and Mir here. Mir provides an ABI; a protocol over sockets is an implementation detail.

OTOH, Wayland is defined as a protocol that runs over a socket.

He's generally right about over-complication, but he either lacks the understanding of just how much X hits his bullet points for bad software; or he wants to stick with the current ball of mud rather than add the complexity of migrating to something that will eventually be simpler (hopefully).

I assume the former, but the later is an arguable position I happen to disagree with.

[1] https://en.wikipedia.org/wiki/ManaGeR

> at the heart of convergence lies the fact that you want to scale across different form factors

I have this feeling one day we'll look back at this and laugh. "Do you remember when they all tried to shove the same interface on all devices? What were they thinking?!"

Umm but even phones have HD displays and 1GHz 64bit processors. Why should that be any different that a desktop system with a 5K display these days?

What we've been lacking was c) people who can articulate a pressingly urgent use case where a new display server is on the critical path, AND have the resources to code it up. Canonical is, as far as I know, the first in that category.

I agree with the supposition that, IF Wayland/Westland represented a suitable head start on meeting the goals that Canonical has with Mir, that Canonical would do well to invest its resources there. Outside of Canonical, there has been a lot of debate as to whether the "Wayland/Westland is the right direction for Canonical" supposition is true.

At the end, I tend to give more weight Canonical's opinion in this matter. They are, after all, urgently developing a project in which a new display server is on the critical path. The risk in foregoing the head start offered by Wayland/Westland is primarily on them.

From the vantage point of this casual observer, Mir has lit a fire for the Wayland/Westland project. That's great! If unifying against a common threat is what pushes the project along at a faster rate, that's okay. But I still tend to think that Canonical is going to win this race by virtue of them having something to strive for on the other side of building a display server.

Wayland is not meant to be doing very much. Its main job is to give programs the buffers they need.

We decided to switch to cloudflare to mitigate some of the load. This requires changing DNS settings, and it seems that for some people, there's been a gap when they haven't been able to access the page. This is of course a little unfortunate. However, it does mean that other people can actually access the page rather than just getting stuck loading.

It's all a bit hectic here at the moment. It's possible there's some other problems that I haven't yet fully discovered.

If it's perfectly fine, then you don't have to upgrade.