cycloptic

Have you seen the stack overflow survey over the last few years? It has some interesting data.

https://insights.stackoverflow.com/survey/2020#technology-mo...

I didn't see any of the tweets so I can't say for sure, that's just my read on the situation judging by the reactions. That's why I said "probably."

If you find a definition of merit that everyone can agree on, please let us know, because that would be news to me. In my experience in the US at least, most people seem to object to there being a central organization that decides who has merit and who doesn't.

That's what I'm saying though, punting it back to academia doesn't increase the general supply, it only increases the supply with a smaller subset of people who are willing to put up with the "old-boys network" aspect for their entire career.

People are probably getting angry at you because you are explicitly invoking a politicized definition of the word merit which basically boils down to "best at maintaining the political status quo." In other contexts the definition is different. (For example Elon Musk's business merits seem to be his track record of making a lot of money, or at least that's what they are on twitter anyway)

If you want other examples of people who are pissed off at the concept of merit for other reasons, talk to some PhDs (or other holders of high academic merit) that are struggling to find work.

Surely you can see how punting the problem back to academia is not a long-term solution. The industry keeps on being an old-boys club that way, and academia can select only for people who are willing to put up with that aspect.

You can't get rid of the distro-oriented shared library system, it exists as long as you are building on top of an operating system. To that end, when you say "we depend on operating system minimum version X.Y.Z" that now becomes another dependency you have to ship at some point if you're running the production machines. Containers are popular because they actually solve that exact problem. If there was some other comparison you were making I'd be interested to hear it, but AFAIK containers can only help here so it's not clear what else you were comparing to.

Hmm, I couldn't find that last time I looked at building Rust -- all I saw was an option to grab precompiled builds of Rust LLVM from the CI server, but maybe I missed something.

Can't there be a build option to not use the LLVM submodule, and instead use the system LLVM? Assuming there are tests for these LLVM bugs, and assuming the patches are indeed being merged, wouldn't a CI be able to catch when it is safe for downstream users that want to use upstream LLVM to update their Rust installation?

You are comparing having containers versus having no containers and no kind of bundling at all, which is not a reasonable comparison. If you need an OS snapshot, the only option on other operating systems is often to use a VM. That's what containers are used as an alternative to. (The other alternative there is to never install patches or upgrades on the production machines, which probably creates as many problems as using containers)

I think you have a misconception of what freedesktop is, it is not much more than a hosting service for desktop-related projects. If someone wants to submit an RFC there the process is the same as it's always been, other people working on that can choose to accept or reject anyone else's proposals. I wouldn't say GNOME or KDE or wlroots or any of those are being a main driver, the point with that is that they have to come together. None of them can just say "I am working more on standardization than you are," that doesn't make any sense when the participation is voluntary.

(And just IMO, things like layer-shell are not really a solution that fits with Wayland, that just puts us back in X territory where clients can position themselves arbitrarily, steal input and take over the screen)

It's not wrong, it was done on purpose specifically because each DE wanted to have the flexibility from using their own graphics server.

In 2021 I don't believe client-side decorations are something anyone can avoid, on any platform.

Please continue hacking on X if that's your fancy, I agree that the codebase is fine as far as legacy codebases go, the real problem is that the protocol itself has issues and that can't really be changed without breaking backwards compatibility or breaking ABI in xlib. Adding yet another security policy to the X server might fix some issues people have, it unfortunately won't fix all the other problems.

Yes, you can run Wayland without a sandbox, but it is being built to work in a case where sandboxes are an option.

Plenty of older window managers don't support it correctly or use non-standard properties. Plenty of newer window managers have non-standard internal properties for unstable features too.

I would not say that Sway is doing anything special here, what they have done is exactly what I was saying earlier: placed the unstable private APIs in the Wayland protocol, with all the problems that entails. Applications should probably not be consuming those APIs directly, they will likely want to go through an abstraction layer.

That would be true if someone refused to use any form of sandboxing, however there are multiple sandboxing solutions available that the "door" works in combination with. That is the only real way to make this kind of security work on an ordinary Linux distribution, the approach used by Android where a new user is created for each application is not really feasible.

There are also ways to sandbox X11, it's a bit harder to do, but you do have some options on how you'd like to do things.

What you are saying is not correct; the xdg-desktop-portal API is not tied to flatpak, it has support for individual windows, it's generic and can be re-used by any sandbox, and it can also be used outside a sandbox. (Snap I believe is using it and it should be not too hard to get it working in other tools like firejail either) Using it has the benefit that your application will also work inside a sandbox and doesn't need to have additional code paths for X11 and wayland and for the sandboxed case. See here for the description of libei, it's not ready yet but is being worked on, and should have a similar design that allows it to work correctly in a sandbox: https://who-t.blogspot.com/2020/08/libei-library-to-support-...

In almost all cases, Wine should viewporter or use fullscreen-shell to set custom resolutions for specific programs, the only reason you would need to allow wine to have access to an xrandr-like API is if you wanted to run your monitor configuration tool from windows, which I strongly doubt people are wanting to do that. If you are using GNOME/KDE, the GNOME/KDE control panel is always going to be the most reliable way to configure that.

Yes you would need to track upstream and keep up with their unstable APIs in order to write such a library that but that's no different than if you asked upstream to do it, they would just be doing that in their tree. (In some cases this is what they do anyway with the xdg-desktop-portal) In any case you would need to be more specific about what it is you want because just saying "implement everything from X11 exactly the way X11 does it" is not useful, that's never going to happen, so let's focus on what actually it is that is needed.

But the thing is it's not really standardized or stable in X11 either, most client-to-client communications are done through various window properties which are not technically part of the protocol and support for them varies between window managers. If your window manager doesn't support it then it's the same, you have to hack the window manager's internals. Honestly, whatever advanced feature it is that you want would be much better achieved by creating a kwin script or gnome extension and then going from there, I believe there is work underway to stabilize some APIs for both of those but as with X window managers, there is a lot of functionality there and there is no guarantee they will stabilize exactly what it is that what you want.

Right, so that would be a place where something like ydotool would come in handy too because fake inputs coming from there wouldn't be coming from the XTEST device.

For screenshots or screensharing, please use the xdg-desktop-portal API. That should work correctly in X11, Wayland, and within a sandbox. For generating fake inputs, a library is being worked on called libei, that also should work in X11, Wayland, and within a sandbox.

For controlling monitor outputs and open windows, those APIs are different because each compositor has a different set of features for what those mean. Generally you should not be using random applications to configure monitor outputs, only your compositor's configuration tool is going to be reliable there. Applications that need to set custom resolutions can use the viewporter or use fullscreen-shell.

Worst case scenario if you need to duplicate parts of the code for all three, I don't think that's a problem. Just put it in a library if it needs to be re-used, the only alternative there is that upstream maintains the relevant bits of that duplicate code, which I'm sure you can see why they would be reluctant to do that.

I can't agree because the alternative would be exposing those unstable private APIs over the Wayland protocol, which would probably not please you either. Some of those X11 APIs are not actually stable and don't actually work everywhere too, they require special support from the window manager.

In Wayland, you would use the same method to manipulate the selection. Read it out from the server, do your transformation, then generate fake inputs to rewrite the text. Running ydotool requires elevated access with suid because that's a privileged operation -- if you're running X11 without a sandbox that has a similar drawback as it allows all clients to intercept inputs and send fake inputs to any window.

That is very possible. Under GNOME and KDE, you would do that with a gnome-shell extension or a kwin script respectively. Those both give you access to the display server's internal APIs. (potentially more than what the X11 server would give you too)

Yes it's in another API and technically not in the Wayland protocol but the functionality is there. It wouldn't make sense to expose all private state of the display server over the Wayland protocol.

I'm very confused, if you don't need a visual user interface, why bother with a windowing system? Isn't the point of that to have visual user interfaces? What functionality is missing?

A solution there would just be to add a similar large chunk of Wine-specific code, which could be an option now if none of the other options work. There is no real other way to do it if the other window systems are going to break the security assumptions in Wayland.

Edit: AFAIK the only real reason X11 needs special support is because functionality that would normally be provided by an X window manager needs to be provided by the Wayland compositor, most of the heavy lifting translating the X11 protocol is done out-of-process in XWayland. The amount of code needed there on the Wayland server side is actually not particularly large, I don't know enough about all usages of the Win32 API to say how that compares.

In general, the wayland protocol is not the same as the X11 protocol and is probably not going to have all the same features implemented in the same way. If it was the same, it would be called the X11 protocol. From a user perspective it doesn't matter what the protocol is or how certain things are implemented, ultimately the only thing they care about is if the application works.

Just my observation, asking for X11-style sandbox escapes to support Wine is a mistake, it's much better to work with the system so it becomes feasible to run Wine applications within a sandbox. It just doesn't make sense to break Wayland's design because of other insecure legacy designs in the Win32 API.

There is always 3:2 pulldown too.

I think that's why TFA is working on some of the features that are missing, e.g. a native Wine port.

You speak as if it's impossible for someone outside Google to maintain a project that isn't written in C++ or C...

How do we know there isn't workplace discrimination or what the actual issue is? It seems that would be something only the company and their employees can answer.

I don't see how you drew that conclusion and I am not sure what you're referring to or how that answers my question, at all. He explicitly says in that tweet that he did not intend to stop the unionization effort. Is there some additional context here?

Edit: I read your comment again and I also am not quite sure what you're objecting to. If there was a movement by wheelchair-bound folks to convince a company to build wheelchair ramps, I certainly hope we would value their arguments over able-bodied folk, because the entire point is they're speaking out about what their experience as a minority person is, and what needs to be done for them to get equal access to a company space. Are you saying their attributes as a wheelchair-bound person wouldn't be important to making that argument?