From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <9front-bounces@9front.inri.net> X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: from 9front.inri.net (9front.inri.net [168.235.81.73]) by inbox.vuxu.org (Postfix) with ESMTP id 0CA5A2438C for ; Mon, 5 Aug 2024 14:58:48 +0200 (CEST) Received: from srv1.howhill.co.uk ([85.95.36.12]) by 9front; Mon Aug 5 08:54:54 -0400 2024 Received: from [192.168.1.223] (Ellychnia-corrusca.howhill.co.uk [192.168.1.223]) (Authenticated sender: willow) by srv1.howhill.co.uk (Postfix) with ESMTPSA id BB01C2F8162D for <9front@9front.org>; Mon, 5 Aug 2024 13:54:52 +0100 (BST) DKIM-Filter: OpenDKIM Filter v2.11.0 srv1.howhill.co.uk BB01C2F8162D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=howhill.com; s=default; t=1722862493; bh=XAeWGsoPEe48SGIs/a3V98EbHEjLWX0GvMwwkYUcHZA=; h=Date:Subject:To:References:From:In-Reply-To:From; b=eRHWQMfaYG5Msy4cxpZPz2DuvzjjNkStO2xNvNNXfffEATypq7551oPOpSbDqCTfh Legej9+ifdnBu0m0LgLdUHm39ukDz4Neh6vy+IZTVfiF60f5nMWH6B4rqMp1YOWEiX nHPkZd8xkCCjVKSomxTWGVy7An7owlewvoKvBRcuLKEG4dvAAJKsWyaTQYXkbpfAbu Sh8V/eNI4WUrUbDTswaxwg/B3xEKP+GkRALTJ0AJXwPKPPAleR3Dd13Yi/UsMNlGHR r7Kv6sgPOBTk5itXQcLMKy24sVea+/rmPpnCXS6bbc7EHZkyF5A93LE3s3H7kc5sKY BgMTk1mnNEHJw== Message-ID: <730aa93a-dbf2-440e-b7fa-0a28c6c5bdd9@howhill.com> Date: Mon, 5 Aug 2024 13:54:51 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: 9front@9front.org References: <6FB99C7720140A4B3969EA601A4B3588@eigenstate.org> Content-Language: en-GB From: Willow Liquorice In-Reply-To: <6FB99C7720140A4B3969EA601A4B3588@eigenstate.org> Content-Type: text/plain; charset=UTF-8; format=flowed X-Spamd-Result: default: False [-2.76 / 20.00]; BAYES_HAM(-3.00)[99.99%]; SUBJECT_ENDS_QUESTION(1.00)[]; GENERIC_REPUTATION(-0.67)[-0.67251240140357]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1] X-Rspamd-Queue-Id: BB01C2F8162D X-Rspamd-Server: srv1.howhill.co.uk Content-Transfer-Encoding: quoted-printable List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: RESTful base property full-stack metadata Subject: Re: [9front] Thoughts on Wayland? Reply-To: 9front@9front.org Precedence: bulk I see your point. Re: the extensions. I was poking around on=20 wayland.app/protocols, but I didn't scroll down far enough to see the=20 mountain of extensions labelled "wlr", "KDE", "Weston", and "External".=20 Jesus Christ=E2=80=A6 I must agree: *Plan 9 is no place for a Wayland compositor.* Still, it might be a place for a remote Wayland client, Arch Wiki=20 summarises the state of the art: https://wiki.archlinux.org/title/Wayland#Remote_display They all use different solutions of course. I suppose the Plan 9=20 solution would be a file server on the compositor machine. I find it funny that most of my interactions with this list have boiled=20 down to "_ can't be that hard, right?", followed by "oh fuck, _ is that=20 hard!" within the space of 24 hours. I really should try and get 9front running on something instead of being=20 a theoretical hacker. Have the Raspberry Pi images been tested on the Pi=20 Zero? - Willow P.S. I wasn't expecting this to blow up as much as it did. This has been=20 a really informative thread, and the talk about GPUs on Plan 9 has been=20 fascinating. On 04/08/2024 22:31, ori@eigenstate.org wrote: > Quoth Willow Liquorice : >> Hello again 9front, >> >> (Warning: long email is long) >> >> I've been leafing through the Wayland protocol, comparing it to rio an= d >> /dev/draw. To me, a system that could speak Wayland sounds much more >> compatible with the wider software ecosystem. >> >=20 > A system that fully implements the posix APIs would also be more > compatible with the wider software ecosystem, however it would not > be more pleasant to program for or interact with; The appeal of > Plan 9 is that it's simplified things to the essentials, and > doesn't pull in a bunch of overengineered junk. >=20 > So, as for Wayland specifically: The biggest problem with it is > that it's not a protocol. It's got a core that's insufficient for > actual use, and a set of mutually incompatible extensisons that > forces each user to write programs that explicitly support wlroots, > gnome, and KDE with separate hacks. To pick on an example, cursor > warping in drawterm only works in some environments, because others > fail to support those specific extensisons. >=20 > On top of that, the protocol's model of resources is rather > overengineered and painful to use. >=20 > More or less, Wayland was misdesigned on different axes than X11; > it's not clear which one is a worse approach. >=20 > However, Wayland is clearly a worse fit for Plan 9 than devdraw; > it's designed for the case where not only does the GPU live on the > same machine as the compositor, it's designed for the case where > every single piece of software doing drawing lives on the same > machine as well. >=20