It also supports iOS.

No, the DRM wouldn’t work at higher levels so you would have the same requirements with regard to 4k.

Please be civil and polite. This type of aggressive comment insulting people because of the tools that they use isn’t welcome here.

Please be polite. If you don’t like a post you can downvote it. If you would like to comment please be more civil.

This is the advantage of decentralization over federation. IMHO the fact that Lemmy is only federated really hurts it. Not so much for user accounts (in theory these can be backed up restored and moved. Not ideal but not awful) but in that communities are tied to servers. When the server a community is on goes away it is hugely damaging to that community.

Death to HDMI. DisplayPort is the superior port.

The problem with separating Calendar + Mail + Contacts is that they work best together. Although to be far I am not aware of an open-source system that effectively combines them.

Calendar event invites an updates go over mail. So you want your calendar application to automatically be able to get those. Also options like “automatically add invites from contacts to my calendar” is an awesome feature. Contacts can also be used for spam filtering (although this integration is a bit easier to do externally).

So currently I am using Nextcloud (self-hosted) although I don’t really like it because it is pretty slow on my low-powered VPS. But even still it doesn’t actually have proper email integration. There are bugs open and slowly moving but I’m still using Thunderbird to process most of my calendar stuff.

Not to mention JMAP which is slowly progressing which would be a huge improvement, especially for mobile clients. It also combines these three services.

Back in the day X was a great protocol that reflected the needs of the time.

1. Applications asked it to draw some lines and text.
2. It sent input events to applications.

People also wanted to customize how their windows were laid out more flexibly. So the window manager appeared. This would move all of your windows around for you and provide some global shortcuts for things.

Then graphics got more complicated. All of a sudden the simple drawing primitives of X weren’t sufficient. Other than lines, text and rectangles applications wanted gradients, rounded corners and to display rich graphics. So now instead of using all of these fancy drawing APIs they were just uploading big bitmaps to the X server. At this point 1/3 of what the X server was previously doing became obsolete.

Next people wanted fancy effects and transparency (like drop shadows). So window managers started compositing the display. This is great but now they need more control than just moving windows around on the display in case they are warped, rendered somewhere slightly differently or on a different workspace. So now all input events go first from X to the window manager, then back to X, then to the application. Also output needs to be processed by the window manager, so it is sent from the client to X, then to the window manager, then the composited output is sent to X. So another 1/3 of what X was doing became obsolete.

So now what is the X server doing:

1. Outputting the composited image to the display.
2. Receiving input from input devices.
3. Shuffling messages and graphics between the window manager and applications.

It turns out that 1 and 2 have got vastly simpler over the years, and can now basically be solved by a few libraries. 3 is just overhead (especially if you are trying to use X over a network because input and output need to make multiple round-trips each).

So 1 and 2 turned into libraries and 3 was just removed. Basically this made the X server disappear. Now the window manager just directly read input and displayed output usually using some common libraries.

Now removing the X server is a breaking change, so it was a great time to rethink a lot of decisions. Some of the highlights are:

1. Accessing other applications information (output and input capture) requires explicit permission. This is a key piece to sandboxing applications.
2. Organize the system around frames to avoid tearing except for when desired (X doesn’t really have the concept of a frame).
3. Remove lots of basically unused APIs like fonts, drawing and many others.

So the future is great. Simpler, faster, more secure and more extensible. However getting there takes time.

This was also slowed down by some people trying to resist some features that X had (such as applications being able to position themselves). And with a few examples like that it can be impossible to make a nice port of an application to Wayland. However over time these features are being added and these days most applications have good Wayland support.