GNU social JP
  • FAQ
  • Login
GNU social JPは日本のGNU socialサーバーです。
Usage/ToS/admin/test/Pleroma FE
  • Public

    • Public
    • Network
    • Groups
    • Featured
    • Popular
    • People

Conversation

Notices

  1. Embed this notice
    mhoye (mhoye@mastodon.social)'s status on Thursday, 26-Jun-2025 22:26:06 JST mhoye mhoye

    Too late to do anything about it now, I guess, but when I remember that there was a fork in the road where one sign said "it's bad if one program window can see what some other program window is doing" and the other said "Blind people should be able to use their own computers", and the Wayland people picked graphic-layer IPC security over humans and I get very sad about it.

    I hear it's getting slightly better now, a decade of heroic efforts fighting the architecture at every step later.

    In conversation about a year ago from mastodon.social permalink
    • Embed this notice
      Rich Felker (dalias@hachyderm.io)'s status on Thursday, 26-Jun-2025 22:28:33 JST Rich Felker Rich Felker
      in reply to

      @mhoye If they hadn't fucked with what works, none of this had to happen. The X11 model works either way depending on your needs. You can give each client a private virtual server where it's isolated from seeing others, or just do this for all but your trusted accessibility tools, or whatever.

      In conversation about a year ago permalink
    • Embed this notice
      mhoye (mhoye@mastodon.social)'s status on Thursday, 26-Jun-2025 22:31:53 JST mhoye mhoye
      in reply to

      And...

      Look, I wasn't there, I don't want to lie about that, my impressions here might be misinformed and at a great remove, but:

      I think the X11 "security" explanation was straight up bullshit.

      I think there are far, far more people who need assistive technology in the world than there are multi-user, possible-malicious-actor GUI-based systems where this threat model is even possible, much less real.

      I think security is really, really easy compared to accessibility so they chose security.

      In conversation about a year ago permalink
      Blaise Pabón - controlpl4n3 repeated this.
    • Embed this notice
      Rich Felker (dalias@hachyderm.io)'s status on Thursday, 26-Jun-2025 22:31:53 JST Rich Felker Rich Felker
      in reply to

      @mhoye The threat model is real when you're running binaries with embedded malware direct from vendors and trying to isolate them in flatpak or full containers or whatever, but access to the X11 screen lets them still spy on you.

      However the solution is proxying their access thru an intermediate virtual X server that doesn't expose other clients to them. We already had tools like this. Not "lol we know better let's throw away standards and reinvent our own shit in the image of Windows, oh and fuck disabled folks too".

      In conversation about a year ago permalink
    • Embed this notice
      mhoye (mhoye@mastodon.social)'s status on Thursday, 26-Jun-2025 22:37:24 JST mhoye mhoye
      in reply to
      • Rich Felker

      @dalias While I agree with the technical point about process isolation, I disagree with your larger point.

      I am 100% ready to believe that architectural decisions made in the 1970s and 80s are a bad mismatch for modern computering expectations. The fundamentals of _what computing is_ is different now. We feel that _everywhere_ in Linux, from the lowest levels up. Unix filesystem perms make perfect sense when computers are shared, bonkers expensive and have professionally-managed backups. But.

      In conversation about a year ago permalink
      Haelwenn /элвэн/ :triskell: likes this.
    • Embed this notice
      Rich Felker (dalias@hachyderm.io)'s status on Thursday, 26-Jun-2025 23:17:46 JST Rich Felker Rich Felker
      in reply to

      @mhoye The things folks are trying to replace unix permissions with (think: polkit) make stuff even worse.

      I agree running everything in same privilege domain is a bad idea, but there are ways to learn from our mistakes while still building on solid primitives, vs YOLO methods to just throw stuff out and replace it with whatever some cowboys (next round: vibe coders) come up with.

      In conversation about a year ago permalink
    • Embed this notice
      mhoye (mhoye@mastodon.social)'s status on Thursday, 26-Jun-2025 23:17:47 JST mhoye mhoye
      in reply to
      • Rich Felker

      @dalias I know you've seen me go on about this before, but today, on relatively-to-90s-mainframes inexpensive home machines, Unix permissions will happily and silently let you destroy everything you've worked on or cared about while protecting you from having to remember where you left that USB stick you put the installer on. We can and should be either revisiting or abandoning nonsense like this at every level. But at an absolute minimum with the goals of safety, accessibility and inclusivity.

      In conversation about a year ago permalink
    • Embed this notice
      mhoye (mhoye@mastodon.social)'s status on Thursday, 26-Jun-2025 23:21:31 JST mhoye mhoye
      in reply to
      • Rich Felker

      @dalias God forbid we learn anything from other people's ideas, systems or experiments.

      (If they'd come from _anywhere else_, Powershell and the Windows perms system would have completely supplanted classic unix perms by now. But no, we can't have object pipes or granular, human-legible safety, those are for the dumdum lusers at windoze micro$oft. Let's all grep/sed strings, sit in a circle and chant "don't break userspace, don't break userspace" together.)

      In conversation about a year ago permalink
    • Embed this notice
      Rich Felker (dalias@hachyderm.io)'s status on Thursday, 26-Jun-2025 23:21:31 JST Rich Felker Rich Felker
      in reply to

      @mhoye It does not sound like this conversation is going to be productive.

      In conversation about a year ago permalink
    • Embed this notice
      Rich Felker (dalias@hachyderm.io)'s status on Thursday, 26-Jun-2025 23:38:08 JST Rich Felker Rich Felker
      in reply to

      @mhoye OK, but I still don't think we're anywhere close to agreeing on this.

      My view is that PowerShell and the Windows perms system are awful, overcomplicated things that essentially zero users understand (and if you can't understand it, you can't use it to secure your stuff) built with the NSA model of security, which is fundamentally wrong.

      But I just mentioned Windows in the context of Wayland's ideas about unfactoring a bunch of layers that should be cleanly factored, based on how Windows never factored them properly.

      In conversation about a year ago permalink

      Attachments


    • Embed this notice
      mhoye (mhoye@mastodon.social)'s status on Thursday, 26-Jun-2025 23:38:09 JST mhoye mhoye
      in reply to
      • Rich Felker

      @dalias Hmmm. I guess I wrote that wrong, because I was trying to agree with you - "we can learn from our mistakes, but also what others have tried". Sorry it came off as confrontational. I've made a slight edit.

      In conversation about a year ago permalink
    • Embed this notice
      Rich Felker (dalias@hachyderm.io)'s status on Thursday, 26-Jun-2025 23:46:14 JST Rich Felker Rich Felker
      in reply to

      @mhoye Yes, as I said, I don't think this conversation is going to be productive.

      In conversation about a year ago permalink
    • Embed this notice
      mhoye (mhoye@mastodon.social)'s status on Thursday, 26-Jun-2025 23:46:15 JST mhoye mhoye
      in reply to
      • Rich Felker

      @dalias Yeah, we're going to disagree on the fundamentals here. My perspective is that - mostly, there's a lot going on there - the windows permission systems and specifically the consequences flipping different toggles in them, are generally much more legible than unix perms and th (often opaque and hidden) ACLs sometimes underneath them. My position is that legibility and accessibility is more important, always, than systemic simplicity.

      In conversation about a year ago permalink
    • Embed this notice
      Raven667 (raven667@hachyderm.io)'s status on Friday, 27-Jun-2025 06:37:26 JST Raven667 Raven667
      in reply to
      • Rich Felker

      @dalias @mhoye ok, but you can do that with Xwayland too. As a technical matter at the point you define a process to run each container with its own Xnest or whatever, don't you need to solve some of the same technical problems with input handling and global key bindings at the window manager level that you do in the Wayland case? What technical purpose would this serve except to keep the pixels X flavored, how do you provide zero copy direct GPU rendering to apps in this case?

      I'm not a desktop app or graphics developer, I just make forms in CGIs for useful little crud apps, but why are we so quick to dismiss the experience and judgement of the seasoned professionals and volunteers who are actually ass-deep in the graphics stack to have good ideas for what is technically a good design. A lot more people who are working no toolkits, window managers, desktop environments, distros etc. seem to think Wayland is a good enough idea to implement it, there is no central authority who can force all these volunteer projects to adopt a change like this, so what do they see that the critics don't?

      IIUC Wayland just defines a very simple mechanism (not policy) for window managers to use the Linux kernel APIs to hand out GPU buffers to apps, and feed them input events, everything else are dbus APIs and conventions from the desktop projects. It has all the same problems with coordination between multiple desktop projects, toolkits and app ecosystems that X11 had which was worked out 30 years ago by the Unix workstation vendors who were trying to build a business on top of it, there aren't as many resources for desktop infrastructure today (my opinion, maybe I'm wrong) because no one is losing a billion dollars if they don't ship next week. There is still _some_ interest, which is why RHEL10 uses Wayland and Redhat pays for FTEs to work on the details like accessibility, but I think this has been primarily volunteer driven over the last 10y.

      In conversation about a year ago permalink

Feeds

  • Activity Streams
  • RSS 2.0
  • Atom
  • Help
  • About
  • FAQ
  • TOS
  • Privacy
  • Source
  • Version
  • Contact

GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.

Creative Commons Attribution 3.0 All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.