5 ms·

Note that this is not Blink the rendering engine that powers Chromium and related browsers, but https://github.com/jart/blink https://github.com/jart/blink, “a

Note that this is not Blink the rendering engine that powers Chromium and related browsers, but https://github.com/jart/blink https://github.com/jart/blink, “a virtual machine that runs x86-64-linux programs on different operating systems and hardware architectures”. Where this talks of running GUI programs, I presume it means that the VM can act as an X client. You would thus still need an X server. I don’t know what may exist along those lines for the web. As for native/desktop hosts, well, I hope you weren’t ever trying to use emulation as any form of security, because the likes of Xorg really aren’t designed for that use case.

eptcyka 4y ago
It runs the X server in the VM.
- Vogtinator 4y ago
  Not in this demo. It probably could though.
  - csdvrx 4y ago
    There's a X with sixel support: https://github.com/saitoha/xserver-sixel https://github.com/saitoha/xserver-sixel I played with this before, and I could use X11 within a mlterm terminal. I should try to recompile it with cosmopolitan to have a single X server binary both for Windows and Linux
    - trenchgun 4y ago
      That's amazing!
      - csdvrx 4y ago
        And this is why I'm so interested in Sixel support for the Windows Terminal (https://github.com/microsoft/Terminal/issues/448 https://github.com/microsoft/Terminal/issues/448) With that and a X server using sixels, there would no longer be a need for something as complex as wslg for most apps: you could just export DISPLAY in your .bashrc, then use one Windows Terminal tab to start X apps, and the other one to display/interact with them.
- chrismorgan 4y ago
  If the X server were running in the VM, how would it display things, or get keyboard and mouse input? You’d need to provide emulated hardware devices, which could be something like /dev/fb0 for output and /dev/input/ devices for keyboard and mouse. All that is a very much larger undertaking, and probably a good deal less useful in general. The likes of X are a much more suitable abstraction. The change here is implementing sendmsg and recvmsg: socket communications, implying communicating with something outside the VM, which in the context of GUI stuff almost certainly means an X server from outside.
deleted 4y ago
[deleted]
destructionator 4y ago
> the likes of Xorg really aren’t designed for that use case. Bullshit. Would be nice if people were to stop spreading these outright lies.
- chrismorgan 4y ago
  I’m curious how you think it an outright lie. I’m speaking of the consequences of Xorg’s basic lack of isolation (because it wasn’t designed for use cases where that matters): that granting access to the X socket allows you to inspect, intercept and modify inputs and outputs for things like key strokes, window contents (yours or others’) and clipboards.
  - deleted 4y ago
    [deleted]
  - destructionator 4y ago
    > I’m speaking of the consequences of Xorg’s basic lack of isolation (because it wasn’t designed for use cases where that matters): that granting access to the X socket allows you to inspect, intercept and modify inputs and outputs for things like key strokes, window contents (yours or others’) and clipboards. This is not true! Both the protocol and the implementation allow for significant separation of server permissions (for example, notice the difference between ssh -X and ssh -Y), and the peer-to-peer nature of things like clipboard means it is quite easy to deny requests on an application level if they're written for it.
    - anthk 4y ago
      XTerm has basic keyboard locking support.
- rom-antics 4y ago
  Straight from the horse's mouth: https://www.x.org/wiki/Development/X12/ https://www.x.org/wiki/Development/X12/ > In short, X11 was designed for a different era of computing. > This is not to say that there's an X12 project. There isn't. But if one day there is... > Systems need to be secure. X12 needs to be designed with security in mind. Do you think the Xorg devs are spreading lies about Xorg?
deleted 4y ago
[deleted]

eptcyka 4y ago

It runs the X server in the VM.

Vogtinator 4y ago
Not in this demo. It probably could though.
- csdvrx 4y ago
  There's a X with sixel support: https://github.com/saitoha/xserver-sixel https://github.com/saitoha/xserver-sixel I played with this before, and I could use X11 within a mlterm terminal. I should try to recompile it with cosmopolitan to have a single X server binary both for Windows and Linux
  - trenchgun 4y ago
    That's amazing!
    - csdvrx 4y ago
      And this is why I'm so interested in Sixel support for the Windows Terminal (https://github.com/microsoft/Terminal/issues/448 https://github.com/microsoft/Terminal/issues/448) With that and a X server using sixels, there would no longer be a need for something as complex as wslg for most apps: you could just export DISPLAY in your .bashrc, then use one Windows Terminal tab to start X apps, and the other one to display/interact with them.
chrismorgan 4y ago
If the X server were running in the VM, how would it display things, or get keyboard and mouse input? You’d need to provide emulated hardware devices, which could be something like /dev/fb0 for output and /dev/input/ devices for keyboard and mouse. All that is a very much larger undertaking, and probably a good deal less useful in general. The likes of X are a much more suitable abstraction. The change here is implementing sendmsg and recvmsg: socket communications, implying communicating with something outside the VM, which in the context of GUI stuff almost certainly means an X server from outside.

deleted 4y ago

[deleted]

destructionator 4y ago

> the likes of Xorg really aren’t designed for that use case. Bullshit. Would be nice if people were to stop spreading these outright lies.

chrismorgan 4y ago
I’m curious how you think it an outright lie. I’m speaking of the consequences of Xorg’s basic lack of isolation (because it wasn’t designed for use cases where that matters): that granting access to the X socket allows you to inspect, intercept and modify inputs and outputs for things like key strokes, window contents (yours or others’) and clipboards.
- deleted 4y ago
  [deleted]
- destructionator 4y ago
  > I’m speaking of the consequences of Xorg’s basic lack of isolation (because it wasn’t designed for use cases where that matters): that granting access to the X socket allows you to inspect, intercept and modify inputs and outputs for things like key strokes, window contents (yours or others’) and clipboards. This is not true! Both the protocol and the implementation allow for significant separation of server permissions (for example, notice the difference between ssh -X and ssh -Y), and the peer-to-peer nature of things like clipboard means it is quite easy to deny requests on an application level if they're written for it.
  - anthk 4y ago
    XTerm has basic keyboard locking support.
rom-antics 4y ago
Straight from the horse's mouth: https://www.x.org/wiki/Development/X12/ https://www.x.org/wiki/Development/X12/ > In short, X11 was designed for a different era of computing. > This is not to say that there's an X12 project. There isn't. But if one day there is... > Systems need to be secure. X12 needs to be designed with security in mind. Do you think the Xorg devs are spreading lies about Xorg?

deleted 4y ago

[deleted]