wayland-explorer VS leapp

Wayland is good until you hit the corner cases that they decided to abandon, without leaving any alternatives. We can always have extra protocol that can be optionally enabled, but good luck with standardizing that. It feels as if Wayland people are abusing their committee to keep Wayland as-is, instead of extending it. The protocol dashboard[1] doesn't look exactly good.

[1]: https://wayland.app/protocols/

Wayland is itself an IPC system (that uses UNIX domain sockets). I would make a custom Wayland protocol (if there isn't already an appropriate one available, look here: https://wayland.app/protocols/). You can define the protocol in XML and generate the boilerplate code in C using wayland-scanner. I assume smithay also has an equivalent of wayland-scanner.

https://wayland.app/protocols/ and https://wayland.freedesktop.org/docs/html/ are just API references.

Given I will be using most of the Wayland protocol to achieve anything (it's minimal) and Wayland is well specified then the 'start at the bottom and build up' design pattern fits. Wayland has a wire protocol based on a Unix socket, and usefully Java has supported Unix sockets since release 16, so I can write everything in Java to (de)serialise messages. This gets me going quickly, providing positive feedback that I'm on the right track..

The core is bare-bones, there are numerous standard protocols since, and many other are in standardization. Here is a site to review their state: https://wayland.app/protocols/

There is some lock-in in some places where tools adopt a protocol that is only implemented by wlroots compositors, or only implemented by KDE, etc, but I suspect this will improve over time as protocols stabilise ( and you can browse the available protocols here: https://wayland.app/protocols/ )

This link comes up in literally every Wayland thread and it is even more bullshit now than it was in 2013 when it was first posted (and it was bullshit then too). It is titled "the real story" but it is quite the opposite.

A few key points:

1) he laughs at how X has a bunch of extensions. https://wayland.app/protocols/ hypocrites much. In 2013, since it was completely unusable, it probably didn't have many. But turns out real world use leads to "useless" features being reimplemented.

2) he complains about how X.org has broad hardware compatibility. As if that's a bad thing. Meanwhile wayland, even now it still doesn't work reliably on half the graphics chips on the market.

3) It complains that certain X features are not fully network transparent. True, but most are and you can detect at runtime and gracefully degrade. Wayland "fixes" this by just dropping the whole feature.

4) it flat-out lies saying the X server does nothing yet it is so much hard to maintain code. The core X protocol provides backward compatibility and is rock solid (and really easy to impelment from scratch btw, someone did it in Javascript for a tutorial for crying out loud). Meanwhile the Wayland compositor keeps accumulating everything because of point 1. Need a screenshot? Add it it the compositor. Need a hotkey? Add it to the compositor. Need drag and drop? Add it to the compositor. Need a notification icon? Add it to the compositor. In X, all those are peer to peer. Graphics are actually a relatively small part of a graphical user interface, something Wayland is still slow to learn.

5) He complains that certain applications are written inefficiently with blocking calls which is inefficient over a network connection. Wayland's calls are ALL blocking and just has no network connection.

6) Complains that X may draw things unnecessarily. Indeed... but there's an extension to disable that. Easy fix. Wayland even uses the same drivers!

So that brings me to Wayland Protocols!. In X11 land, X11 defines a lot of behaviors for you. There is no such definition in Wayland-land by design - this is to give compositors a lot more freedom and flexibility in how they function. It also means that it required time for protocols to develop to cover all of the things that we would need in a desktop window compositor to bring it up to snuff for desktop usage. These protocols evolved through the past 4-5 years of everybody seeing it's shortcomings on a Desktop system compared to a mobile phone based UI. With the latest fractional scaling protocol we have more or less finally "closed the gap" between Wayland and Xorg on the desktop - it's just a matter of compositors implementing full support for all of the protocols people want.

Summary:

Do you find yourself overwhelmed with work, requests, or complaints and in need of assistance to alleviate the pressure, enhance communication, facilitate organization, prioritize tasks, and foster greater trust and transparency?

Alternatively, I can work as a full stack developer.

AWS Community builder, AWS User group Leader, public speaker (https://www.youtube.com/watch?v=qdu58NAQfU0&t=271s)

Or perhaps you need both? =)

I have 4+ years of experience as a product manager and 8 in product development (before pm: agile coach, UX designer, and developer).

I've been the co-founder of the open-core company behind the OSS project Leapp (https://github.com/Noovolari/leapp)

Please feel free to reach out.

You can switch to saml2aws using the browser method instead of the Okta method and it will continue to work after the upgrade. There is also a really neat GUI tool to manage your session tokens that also works. https://www.leapp.cloud

Take a try to Leapp: https://github.com/Noovolari/leapp

Hello everyone, I'm the maintainer of an open-source DeveloperTool (https://github.com/Noovolari/leapp)

With a heuristic of 7000 users daily, I started feeling the need to have more information on how Users are using the project to improve it.

Is it the right thing to do to create a better Developer Experience and gain feedback for the end users?

On a side:

- For all your employees I can advice you Leapp as open-source project (https://github.com/Noovolari/leapp). It solve mayor of the problem listed here:

I am looking to manage Leapp (https://www.leapp.cloud/) from the StreamDeck. Leapp allows you to manage and switch between different Cloud Accounts (AWS, Azure, etc). Leapp has a command line interface which I could automate with a StreamDeck plugin. Unfortunately it looks like the only official SDK is the sandboxed JavaScript one. This means I cannot automate command line tools with it.

If you’re wondering if there is a tool that allows you to stop thinking about AWS credentials and where to store them in the right way, give a look at Leapp! It takes the responsibility of storing long-term credentials in the system vault, generating/refreshing short-term credentials, and placing them in the right place for the clients to use them.

Still, there is an elementary problem that we need to address, and it’s more on the operational side of things. Once we secured and implemented a tremendous multi-account strategy, how do people access AWS accounts? It turns out there is a fantastic open-source tool that lets you handle that with no effort, and its name is Leapp.

When you have to configure access to multiple AWS accounts using the Assume Role access pattern, it becomes difficult to get rid of all the Named Profiles configuration data and relationships. When you’ve to deal with a complex access scenario, tools like Leapp (https://www.leapp.cloud) come to the rescue! Leapp avoids you to specify relationships between Named Profiles in the config file, as the access methods are stored in the tool-specific configuration file.

Leapp Github repository