emersion

Facebook's strategy to achieve this is to disallow people from having two different accounts. Things are different on e.g. Twitter where it's common to have two accounts for different usage (like email).

Do you suggest disallowing people from having two different email addresses?

efail can be fixed, see the link you posted, section "mitigations". Also note that (1) disabling HTML emails fixes it (2) not all clients are affected.

CSV is just an example, data vendors can choose e.g. JSON if they want more a sane and well-defined format.

>The single SQL endpoint is well suited for a data marketplace. Data vendors currently ship data in CSV files or other ad-hoc formats. They have to maintain pages of instructions on ingesting this data. With Splitgraph, data consumers will be able to acquire and interact with data directly from their applications and clients.

I appreciate the effort to make it easier for users to access heterogeneous data sets, but I really hope data vendors keep shipping raw CSV files. I don't want a company to gate access to the data, merely offering a proxy. I want to be able to download the whole raw datasets from the vendor directly if I want to.

This sounds like a browser bug tbh.

Just say it's your <instance name> channel instead of saying it's your Peertube channel. You don't necessarily need to explain what Peertube is each time.

Also, searching for your account on any Peertube instance should work fine.

>When I sign up for gmail, I can just be myself. I don't have to be myself + something else.

Well, it's still you + gmail.com. It could be you + fastmail.com, it could be you + posteo.de, it could be you + <insert other e-mail provider>. You still chose gmail over another provider, like you could choose cucumbers.pizza over another provider in the case of the Fediverse.

aerc [1] supports arbitrary content filters (programs invoked when showing a message body). These are used for quote and diff highlighting. It would be nice to write a filter that auto-links tickets and commits depending on the List-Id.

[1]: https://aerc-mail.org/

Many of these features can be implemented in lists.sr.ht.

lists.sr.ht already has support for threads and diff highlighting. Example thread: https://lists.sr.ht/~emersion/public-inbox/patches/7077

Hmm, but then "apt install" would just fail because of an unresolved dependency right?

>This happens in a buffer and is normally one display update behind in time.

This assumes compositors perform their work right after each display refresh. Compositors can decide to perform their work later, some amount of time before the next display refresh (e.g. a few milliseconds). This allows to reduce latency because the new buffers submitted by clients (such as web browsers) can be displayed with less than 1 refresh period worth of latency. For instance the browser can update its buffer at last display refresh + 8ms, then the compositor can composite at last display refresh + 13ms, and the new frame can be displayed at last display refresh + 16ms.

Here's for instance how Weston does it: [1]. Sway has a similar feature.

>However since pointing with a cursor is such a core experience in these OS'es, the "screen compositor" usually have special code to draw the cursor on screen as late as possible—as close in time to an actual display refresh as possible—to be able to use the most recent position data from the input device driver.

That's not entirely true. Nowadays all GPUs have a feature called "cursor plane". This allows the compositor to configure the cursor directly in the hardware and to avoid drawing it. So when the user just moves the mouse around the compositor doesn't need to redraw anything, all it needs to do is update the cursor position in the hardware registers.

Compositors don't have code to draw the cursor as late as possible. Instead, they program the cursor position when drawing a new frame. (On some hardware this allows the compositor to "fixup" the cursor position in case some input events happen after drawing and before the display refresh.)

But in the end, all of this doesn't really matter. What matters is that the app draws before the compositor draws, thus the compositor will have a more up-to-date cursor position.

[1]: https://ppaalanen.blogspot.com/2015/02/weston-repaint-schedu...

Unfortunately, it seems like I remembered correctly, at least for Chromium: https://news.ycombinator.com/item?id=22972856

It seems like on recent Ubuntu installations some packages are provided by snaps (ie. "apt install XXX" will install a snap). I'd be interested in disabling this behaviour, if anyone knows.

The article doesn't make it clear how many such cases there are:

> The South Korean figure had risen from 51 such cases on Monday.

> "The number will only increase, 91 is just the beginning now"

This reminds me of openring [1], which is a little box you add to your blog with links to latest articles on blogs you follow.

[1]: https://git.sr.ht/~sircmpwn/openring

Which compositor are you using? If you don't have a GPU you'll want one with software rendering support. Using a software OpenGL implementation like llvmpipe will work but will be very slow.

We don't support this yet in wlroots, but it's definitely something we want to add, and not a limitation of the Wayland protocol at all.

Side note: FreeBSD, i3 and X11 aren't the easiest pieces of software to use if you don't want to spend time dealing with configuration files. There are better macOS alternatives for your use-case!

I believe job_id is an int in this case. Buy yeah, it doesn't hurt to double-check, just in case it somehow gets called with a user-supplied variable at some point.

These things are managed by your compositor, not Wayland itself. Which compositor are you using?

No, 0.0.0.0 will still be reserved.

>0.0.0.0/32 is still prohibited, of course.

X11 is a pile of hacks. Have you ever tried to read the source code? When the X11 devs design a new system and stop maintaining X11, it's likely that X11 is not in a good shape.

>This isn't a good thing to me, especially considering NVIDIA hardware doesn't seem to be well supported. Someone come along and correct me, please.

It's the other way around: NVIDIA doesn't support GBM, the standard for buffer allocation.

A lot of what you're saying seems due to a particular Wayland compositor, not to Wayland.

Redshift works with this patch: https://github.com/jonls/redshift/pull/663

>All these dependencies seem to be getting more or less mandatory.

Note that Wayland is not a _new_ dependency. It's a dependency that replaces X11.

NVIDIA doesn't support GBM, which is the standard for buffer allocation. Use nouveau.

>The last issue could be solved with a reusable library that provided basic compositor functionality for window managers.

This is pretty much what wlroots is.

Yes. Note that this isn't really possible with X11.

(Only replying to points that make sense to me)

>Consistent window decorations?

We have a protocol for this for compositors that want to support it: https://gitlab.freedesktop.org/wayland/wayland-protocols/tre...

>Redshift?

Works on GNOME, KDE and Sway.

>Global keybindings?

We prefer to let users configure those in their compositor's configuration file.