genode VS libsixel

seL4 foundation members[0] are using it.

There's Genode[1], which supports it among other kernels, offering a fancy desktop environment.

However, efforts like this driver framework do help. There's also Makatea[2], an effort to implement a stronger Qubes-like system based on seL4.

0. https://sel4.systems/Foundation/Membership/

1. https://genode.org/

2. https://trustworthy.systems/projects/makatea/

> While this is true from a certain perspective, machine code creates a system which must grand access to many things to become usable. A shared file system is a good example of this. Some software could easily echo a line into you .profile that tries to launch a key-logger, and this works in many cases.

That's common, but it's certainly not a requirement to run native code. For example, we've done a pretty good job at retroactively fixing that while preserving backwards compatibility with containers (I can, and have run normal official Firefox binaries inside a docker container with zero access to my real home directory) or sandboxes like flatpak (bubblewrap). If you want to run real native binaries but don't have to preserve backwards compatibility, then it gets easy; genode ( https://genode.org/ ) does a lovely job of truly practicing only giving programs what access you want to give them.

> The expectation of software existing as opaque files creates a huge amount of work for the OS in verifying the exact behaviour of the software as it runs (and in ways which can often be circumvented), rather than a source-based approach in which malware is never allowed to touch the processor.

I think you're overoptimistic regarding what you can do with the source code short of manual (human) auditing. I mean, sure there are things you can scan for to try and catch bad behavior, but in the case of actual malice I wouldn't trust automatic code analysis to protect me.

>> I'm typing this on a nice comfy GNU/Linux box where the only blobs are some firmware

> So you suffer the worst of both worlds then. You've had to download and compile the source yourself, but as the software is designed around being distributed as blobs, so you enjoy none of the benefits that might come from source distribution.

I have no idea why you think either of those things? Depending on the distro I certainly can compile from source on my own box (ex. Gentoo, NixOS), but I can also use precompiled binaries (ex. Debian, NixOS) while still having it be trivial to go find the exact source that went in to the binary package I downloaded (this has gotten even stronger with Reproducibility efforts meaning that I can even verify the exact source and build config that created a specific binary). The actual application software and OS are available as Open Source code that can be audited, with binaries available as a convenience, and the only remaining blobs (unwelcome but impractical to fix so far) are firmware blobs with relatively constrained roles (and on machines with an IOMMU we can even enforce what access they have, which is a nice mitigation).

Genode[1] is slowly approaching the point at which I can use it as a daily driver. I hope it makes it before Windows 10 goes away. It will be nice to never have to work about viruses, or spyware, etc., any more. It'll be like a trip back to the free spirited days of DOS and write protected floppy boot disks.

[1] https://genode.org/

I'd dig into genode[1], which is a capability based operating system. You'll likely see an upsurge in interest in capability based systems in the next decade.

[1] https://genode.org/

Yet another exploit that just wouldn't work on a well-designed system, such as Genode[0].

0. https://genode.org/

Have you looked at Genode? I don't think it's usable day-to-day yet but the concepts seem interesting.

Maybe you should go into details a bit more what you are planning and why. There are (and have been) several approaches here. The most prominent might be Genode (https://www.reddit.com/r/genode, https://genode.org) and joining forces there might be a better approach than starting another project that will get lost in the details and complexity eventually.

Library you can use to generate these images:

https://github.com/saitoha/libsixel

Plenty of links to other projects.

Sixels are pixels and enjoy a wide support due to how old it is.

Kitty protocol is PNG or primitives - which BTW would make it great for a GUI library.

Different tools for different needs, but if you are going for a wide support you want something simple that doesn't have 5 different types you have to separately implement and test:

> d: Direct (the data is transmitted within the escape code itself)

> f: A simple file (regular files only, not named pipes or similar)

> t: A temporary file, the terminal emulator will delete the file after reading the pixel data. For security reasons the terminal emulator should only delete the file if it is in a known temporary directory, such as /tmp, /dev/shm, TMPDIR env var if present and any platform specific temporary directories and the file has the string tty-graphics-protocol in its full file path.

> s: A shared memory object, which on POSIX systems is a POSIX shared memory object and on Windows is a Named shared memory object. The terminal emulator must read the data from the memory object and then unlink and close it on POSIX and just close it on Windows.

> What nonsense, it takes literally 15 lines of code without using anything beyond the standard library to write a client

Conveniently taking a preencoded PNG and assuming away the necessary queries of supported protocol:

> Since a client has no a-priori knowledge of whether it shares a filesystem/shared memory with the terminal emulator, it can send an id with the control data, using the i key (which can be an arbitrary positive integer up to 4294967295, it must not be zero).

> for the kitty graphics protocol. I challenge you to match that for sixel

https://github.com/saitoha/libsixel/tree/master/perl

    use Image::LibSIXEL;

Also:

https://github.com/saitoha/libsixel

contains img2sixel, which lets you dump images to the terminal. It can also do animated GIFs.

Video:

https://github.com/saitoha/FFmpeg-SIXEL

GUI apps:

https://github.com/saitoha/SDL1.2-SIXEL

and more, linked from the libsixel repository.

Not sure of Terminal emulator capabilities on Apple devices, but thanks to https://github.com/saitoha/libsixel , several applications, including emacs very much support image output in terminals.

You don't have multi-colored terminal output? Even legacy systems have long had Sixel support.

> SIXEL is one of image formats for printer and terminal imaging introduced by Digital Equipment Corp. (DEC). Its data scheme is represented as a terminal-friendly escape sequence. So if you want to view a SIXEL image file, all you have to do is "cat" it to your terminal

https://github.com/saitoha/libsixel