emersion

A really nice article by Pekka Paalanen from Collabora. He's been working for a while on bringing color management & HDR support to Wayland [1], producing documentation and discussing with upstream (kernel driver) and downstream (video players, browsers, etc) developers along the way.

https://www.collabora.com/news-and-blog/blog/2020/11/19/deve...

Indeed! Maintainer here. I just lived in Korea for a while and remembered a Korean dish while trying to find a project name.

tl;dr no particular reason. :)

Interestingly, IRC operators also combat spam. But they never ask your phone number.

Spam does happen on IRC, but gets shut down eventually. Same as Discord and other messaging platforms.

> ignored by the Wayland developers

Feel free to improve and/or review it. Maybe it's very important to you. But it may no be very important to other contributors, and said contributors are just volunteers.

It's pretty common to copy-paste POSIX sh one-liners, or `source` a simple script. fish makes this annoying to do.

> You can configure your shell using a web interface! Just run fish_config

As much as I like the fish shell, I really consider this an anti-feature. A TUI application to configure the shell would make much more sense. The terminal emulator is your platform, not the Web.

Vulkan and OpenGL are provided by drivers, not by the OS. It's a perfectly normal situation, what else _could_ Microsoft do?

> OpenGL compatibility pack

This is using the Mesa Gallium state tracker with a DirectX backend. It's not meant for vendors with a native OpenGL driver.

If you just have a handful of dependencies (which themselves have few to no transitive deps) then it works just fine.

I'm using ES modules for a webapp I maintain, and it's just nice to be able to run it without any build step. Just fire off a local static HTTP server and you're good to go. There's an optional production build step which can be used if desirable.

This article is about writing an X11 window manager, which is a different piece of software. An XWM is an X11 client. Writing an X11 server is a much more involved effort (there's a reason why there's only one widely used implementation, Xorg).

Feel free to continue using X11 of course, no one's forcing anybody to switch. That said:

> Does upstream Wayland work on any platform except for Linux?

Yes, FreeBSD. Patches welcome to make it work on other BSDs.

> Does this display server have any form of colour management for, you know, the stuff it's displaying?

No more than X11 right now, ie. none. But it's in the works.

Using X11 as some kind of client-to-client IPC was really just a hack in the first place.

This kind of workflow can be achieved with GitHub or GitLab issues by using labels. For instance, I often add a waiting-on-reporter label when asking for more info.

Packages aren't supposed to be submitted and maintained by the developers themselves. The distribution maintainers and community is supposed to do it.

logind has a replacement: https://git.sr.ht/~kennylevinsen/seatd/

I wish DNS providers supported the standard DNS update protocol, instead of having each their own custom HTTP API.

ARC requires the recipient to trust the mailing list. Better to just allow recipients to check the original DKIM signature instead.

It depends. I've seen some servers with a DMARC policy which fails when SPF fails.

DKIM completely supersedes SPF, hence my recommendation to just skip SPF.

> The ML server will verify the original authors SPF. The N recipients will verify the ML servers SPF - the chain (which matches the series of MTA's involved) is still verified end to end.

The recipients have no way to check that the mailing list server has checked SPF/DKIM/DMARC. Mailing lists very rarely drop messages because of a failing SPF/DKIM/DMARC check.

ARC tries to fix this, but requires recipients to trust the mailing list server. Just using plain DKIM is much better, recipients can just treat ML-forwarded emails just like direct emails.

Alright, I took a shortcut: SPF will verify, but for the wrong domain. It'll break when used together with DMARC's alignment checks.

I'm eating everyday, and I'm not working on closed-source software, only open-source.

It's perfectly possible to get money _and_ write open-source software.

SPF will always fail. OTOH, when the mailing list doesn't do dumb stuff like mutating the subject or the body, DKIM will succeed.

A mailing list will _always_ break SPF. When forwarding messages to mailing list subscribers, the mailing list server will not match the host in the "From" header field.

Don't use SPF. It breaks mailing lists. DKIM does not, assuming a correctly configured mailing list.

Not being able to publish closed-source apps is a feature.

A little disappointed to not see Linux mentioned in any of the timelines.

Picture of the fire from last night: https://twitter.com/BobZeHareng/status/1369563084277374980

No, DKIM doesn't break forwarding. If you just forward the message, the original DKIM signature remains correct.

The original DKIM signature breaks if you edit the message body or its existing header fields.

Use anime character names. That way you have an excuse to collect cute artwork for these machines.

IIRC the plan is to have a proper self-hosted Git repo, and mirror it on GitHub.