Weston Might Move To 4 Month Releases While Wayland's Maturity May Stop Timed Cycles

[oiaohm]

The more stuff in Wayland the better, because then people wouldn't devise different solutions for the same features. I mean Wayland is a protocol not a product so it's ok to be bloated.

What you don't understand is x.org X11 server implements less than 10 percent of the X11 protocol. Its not ok for a protocol to come bloated it reduces the amount of force you can put on core features. Every bit of bloat comes excuses. We did not implement X feature because it was not required line.

You said that Weston, the "reference" implementation, implemented screen capture. But gnome did not follow in the same way. This means that "screen capture" is NOT PART of the spec, which is THE WHOLE PROBLEM man. Wake up.

Wake up gnome not following would have happened be it reference implementation or in the specification. Like a wayland application is meant to stay running if compositor shutdown down and reconnect to it when compositor restarts this is feature of protocol not implemented in Gnome. I would say this feature is kind more critical than screen capture.

How the fuck is something a "reference" implementation if it implements extra features? Reference implementations are supposed to implement only the API or protocol or format itself, not "extensions" because then it's not a reference implementation anymore.

This is being clueless. Reference implementations do two things. 1) implement the standard. 2) implement feature for peer review to be include in future standards.

The fact that Weston had to implement features outside the Wayland protocol speaks volumes about Wayland's design.

This says you are clueless. Because a reference implementation is meant to be the bleeding edge of the protocol. The fact you are seeing the bleeding edge in Gnome and other places is major nightmare. Its not that the wayland development process is wrong you don't want anything in the protocol that cannot be in fact implemented this is why the reference implementation has to be ahead of protocol. Remember if anything gets into protocol that cannot be implemented it comes excuses not to implement the complete protocol.

They don't have to use the same theme from the same place. It just has to be DEFINED instead of leaving it off to 3rd parties.

Thinking wayland protocol does not do decorations it does not make sense to define it in protocol. Some of this comes common sense when you start thinking about. DPI setting is not accessibility? This stuff I agree need to be defined I don't agree that it need to be defined as part of wayland protocol particular when a accessibility protocol exists and implementing accessibility protocols are mandated by law. We already know wayland compositor coders are disobeying standard so there is no point add any extra to that standard.

Nah it's not "kind of required", it's not required at all. If you want a sandbox then use dedicated software for it, not an application distribution. Obviously Wayland is also limited on purpose in features for "sandboxing" bullshit (aka tablet use of computer).

Run files did what you said as a solution. They were caused of many system crashes. LOL sandboxing bullshit how clueless can you be.

Kind of sandboxiing around applications starts on windows with windows 2000 and extended on Vista. https://en.wikipedia.org/wiki/Window...rce_Protection
This is not a full blown sandbox But this prevents third party apps that have not had approve from overwrite core system files and causing system to fail. If you look at OS X dmg handling you find it doing the same things. This has nothing to-do with tablet use of computer. Its what you have to-do to support installing third party applications from non certified sources so they don't ruin your OS. The earliest form of this file system sandboxing appears on Unix with chroot of course this never matured into easy to use end user solution.

Yes flatpak also is protect the user home directory so that a flatpak application configuration files do not overwrite the same application installed by distributions configuration files. Done in ways that this is not even possible with a coder error. Then due to issue with items provide over dbus you need to sandbox this as well. Now its not very much more of a step to go stuff it and do a full sandbox.

Wayland limiting down what applications can see was not just done for security. This was done in the theory that correct written applications could keep on running even if the compositor crashed and reconnect to the compositor when it restarted. So that the data lost inside the compositor due to crash should not be harmful to application.

Let me tell you something, lack of features is way worse than bad security. I mean if it wasn't, then go plug off your internet completely. Then you're 100% secure, who cares you lost access to the internet right? Features and usability don't matter, only pseudo-security does. /sarcasm

Thinking that you only sandbox for security is wrong. Sometimes you sandbox for compatibility reasons. Sometimes you want to for crash isolation. Sandboxing design inside wayland is for security and crash isolation. Sandboxing inside flatpak is for security, compatibility reasons and crash isolation. Crash isolation so that one part can fail without taking everything else with it.

Wayland done right should be more durable than X11. Due to what gnome and others have done there is high odds that something like xpra will have to made for wayland to wrap wayland applications to restore the crash isolation that is in the standard. Of course lack of proper buffer management in kernel by Nvidia also gets in way of proper crash isolation in Wayland.

[Weasel]

Wake up gnome not following would have happened be it reference implementation or in the specification. Like a wayland application is meant to stay running if compositor shutdown down and reconnect to it when compositor restarts this is feature of protocol not implemented in Gnome. I would say this feature is kind more critical than screen capture.

Like I said, now it's Wayland's fault. If it was in the spec, then it would be gnome's fault.

The difference is important, because you'd see me and others bash on gnome instead of Wayland. (well, not like I even use gnome, but whatever)

This says you are clueless. Because a reference implementation is meant to be the bleeding edge of the protocol. The fact you are seeing the bleeding edge in Gnome and other places is major nightmare. Its not that the wayland development process is wrong you don't want anything in the protocol that cannot be in fact implemented this is why the reference implementation has to be ahead of protocol. Remember if anything gets into protocol that cannot be implemented it comes excuses not to implement the complete protocol.

I've no idea in what world you live in, but design comes way before implementation. At least in proper projects. But I forgot some people, like gtk devs, break APIs "as they develop" because it's too hard work to make a proper design first and stick to it. This has nothing to do with any particular project. It's just common sense and proper practice.

Run files did what you said as a solution. They were caused of many system crashes. LOL sandboxing bullshit how clueless can you be.

Kind of sandboxiing around applications starts on windows with windows 2000 and extended on Vista. https://en.wikipedia.org/wiki/Window...rce_Protection
This is not a full blown sandbox But this prevents third party apps that have not had approve from overwrite core system files and causing system to fail. If you look at OS X dmg handling you find it doing the same things. This has nothing to-do with tablet use of computer. Its what you have to-do to support installing third party applications from non certified sources so they don't ruin your OS. The earliest form of this file system sandboxing appears on Unix with chroot of course this never matured into easy to use end user solution.

This has nothing to do with sandboxing, it's permissions and ACLs. I'm guessing to you even the basic unix permissions are sandboxing right? But then why need another layer of sandbox on top of flatpak?

Rest of the points were valid, but we definitely don't need sandboxing for that. It's called simple redirection or writing portable applications, especially since flatpak allows you to install "local" apps on a per-user basis. All such apps should write their config into their own directory, just like portable windows apps, which btw a lot of people love for simplicity. I guess it's too much to expect convenience out of most "Linux solutions to Windows alternatives". As usual.

And macOS has a terrible design so not gonna bother.