Fedora COSMIC Desktop Spin Being Considered

[anda_skoa]

google (and many others) seem to have settled on xsecurelock for their employees infrastructure

https://github.com/google/xsecurelock

Good resource: the intro of its README has good examples of the difficulty of external lockers that simply can't happen with one that is part of the display server.

Which would of course be possible on X11 but is just not very common (if available at all).
It is more likely to be the case with Wayland as display server and compositor are usually one and often not a third party component.

Hence the assumption that screen locking would be less of a problem for COSMIC than what was suggested in the post I replied to.

if a project like cosmic is going to get wider acceptance its probably going to need to support the authentication modules written for that.

As you can see in its dependency list it is using libpam
Which is not surprising given that this is Linux's main authentication system with tons of plugins for various auth technologies.

Great system as it applies to graphical logins, local consoles, SSH, etc.
Pretty easy for example to add Google Authenticator based two-factor check

"the hard bits of locking" is that no single process (even a wayland compositor) owns input or output

They whole point of a Wayland compositor is to own both input and output.

[royce]

This is why I keep saying that the System76 folks should make COSMIC closed source and only available to their customers, at least for a short time.

Oh yes, I'm sure this would go down well with their customer base, a lot of them OSS enthusiasts 🙄🤌🤌

[mSparks]

.
An X11 server could of course implement locking directly and would thus only have to deal with the reduced complexity compare to the usual choice of delegating it to a separate application.

google (and many others) seem to have settled on xsecurelock for their employees infrastructure

https://github.com/google/xsecurelock

if a project like cosmic is going to get wider acceptance its probably going to need to support the authentication modules written for that.

And, again, even if the choice of asynchronous technique is a separate process, it can just deal with the authentication and still keep the hard bits of locking in the process that controls input and output.

"the hard bits of locking" is that no single process (even a wayland compositor) owns input or output, in fact in most situations no single machine controls input or output. I've not seen any wayland compositor even start, let alone come close to solving those problems.

[anda_skoa]

I am not aware of any X11 server that does not control both input and output, what was your point?

The point is that they don't implement screen locking but delegate it to another process which then has to deal with not having that level of immediate control.

It is not a consequence of either technology but a difference in architectural choice that makes a use case more or less complex.

Asynchronous means that things are not happening synchronously

Obviously.

And as said before there are many techniques to do that.
So even if some forms of authentication require asynchronous handling it does not imply doing that in a separate process.

And, again, even if the choice of asynchronous technique is a separate process, it can just deal with the authentication and still keep the hard bits of locking in the process that controls input and output.

X11 file servers and wayland system calls to create streams of bytes do exactly the same thing, with exactly the same libraries

See above.
An X11 server could of course implement locking directly and would thus only have to deal with the reduced complexity compare to the usual choice of delegating it to a separate application.

Equivalently, if you choose to delegate that on Wayland, you also have additional complexity.

A desktop project like COSMIC has all four options available:
* using an X11 server with built-in screen locking, e.g. a fork of Xorg with that additional feature
* using an X11 server which delegates screen locking, e.g. Xorg and xscreensaver
* using a Wayland compositor with built-in screen locking
* using a Wayland compositor which delegates screen locking

Given COSMIC's choice of Wayland that leaves them with two of those, I assumed they went with the simpler one.

[mSparks]

You don't have to but I am not aware of any Wayland compositor that does not control both input and output.


Asynchronous doesn't mean out of process.
There are also event loop based asynchronous operations, multi-threading, co-routines, etc.

And since compositor implementing screen locking can easily handle authentication out of process, they can use any of those mechanisms as well if that first their technology stack.

No need to complicate things by running the whole locking out of process

I am not aware of any X11 server that does not control both input and output, what was your point?

Asynchronous means that things are not happening synchronously, X11 file servers and wayland system calls to create streams of bytes do exactly the same thing, with exactly the same libraries, there is nothing magical about using system calls instead of file handles that makes the job of locking a complex asynchronous desktop environment any easier, quite the opposite in fact, it is much easier to lock down a few file handles than it is to ensure a system call completed successfully and nothing else can call other system calls that break the locking mechanisms, qudos to system76 in that rust offers a lot more tools to do that than you get with C/C++, but this hand wavvy "wayland good, X11 bad" has been shown to be pure hyperbole time and again now.

[marlock]

Given other news where devs (re)developing things in Rust and commenting how fast it was to develop things into a useable state...

...i wonder how much time it would take to do the same thing with C (or whatever unholy mix of things a DE uses)

Too bad we can't navigate the multiverse to find a suitable control group Rust-less world and actually measure how much development time Rust saved in this instance

mmstick, could you share an insider perspective on this? Is it actually different using Rust? Is there anything that it just doesn't do, or doesn't do well enough yet?

[anda_skoa]

Also, I don't believe you

You don't have to but I am not aware of any Wayland compositor that does not control both input and output.

because performant IO requires that IO to be asynchronous, if you make the whole desktop pause every time you move the mouse users will complain a lot.

Asynchronous doesn't mean out of process.
There are also event loop based asynchronous operations, multi-threading, co-routines, etc.

And since compositor implementing screen locking can easily handle authentication out of process, they can use any of those mechanisms as well if that first their technology stack.

No need to complicate things by running the whole locking out of process

[mSparks]

Sure, but I wasn't talking about libraries.

A Wayland compositor has the advantage of controlling input and output in the same process.
There is no asynchronous communication that complicates things.

Worked well for windows phone, what can go wrong.

Also, I don't believe you, surely that is down to whether the compositor was written by someone competent with writing software developed for consumer hardware released in the last 30 years or not

Why would that require to run the screen locker out of process?

because performant IO requires that IO to be asynchronous, if you make the whole desktop pause every time you move the mouse users will complain a lot.

plus most linux software doesn't just run out of process, its often split over multiple machines.

[rmfx]

Yeah man, I'm a troll as is anyone that has an opinion that is contrary to yours and other Linux advocates.

It's not possible that i just see things differently than GPL zealots.

If open source models give you a skin rash, stop checking (and commenting) on Phoronix. The entire site is dedicated to opensource.
Nobody will change their philosophy because a troll keeps telling over and over that companies should go closed source…

[muncrief]

i saw your theme and it does look a lot like win7/10 glass themes, which IMHO is the best windows ever managed to look like... win8 imho was a fiasco with excessive flattening of UI elements, which caused overlapped windows to be hard to distinguish from in-window UI segments, etc (it kind of regressed to win 3.11 graphical identity but even less border hinting, LOL)

given how much you talked about and emphasized colors in your theme, i think you might like Linux Mint Cinnamon with the new stronger accent color themes, though they're using accent colors in less places now (the "L"/legacy themes had softer colors but used those in more places)

at the very least you may be happier with Cinnamon than GNOME because theming isn't broken on purpose every so often, so worst case scenario you still have to make a custom theme but it should last longer and break less spetacularly

Thank you for the suggestions marlock, but I run Arch on my workstation and Manjaro on my media server and would never use anything other than XFCE because I like simple and efficient desktops, and don't like all the convolution and inefficiency other DEs impose. I'm glad Linux gives us so many choices though, because I understand other people like the more complex DEs.