moonpiedumplings

None. The Apple App store straight up disallows AGPL and GPL licensed code on it.

Sometimes people mistake platforms banning or refusing to use A/GPL licensed code as restrictions of the license itself, and that's what they refer to by "The A/GPL is 'restrictive'" — because A/GPL licensed code can't be used on every platform.

It's worked fine for me with no configuration. If you ask for help, we can troubleshoot and get it working.

I despise the way Canonical pretends discourse forum posts by their team members* are documentation.

I've noticed they have been a bit better lately, and have migrated much of the posts to their documentation, but it seems they are doing it again.

As this is developed, we will update this post to link to the new documentation and feature release notes.

Pro tip: You could have just made the documentation directly, with the content of this post. Or maybe a blog post. But please stop with the forum posts. They are very confusing for people not used to these... unique locations.

*Not that people are easily able to find this out when they don't give any indication that the forum post is something other than just another post by a rando. Actually, I'm just guessing here, based on the quoted reply, for all I know this could be a post by someone unrelated to Canonical. The account is 3 months, and the post itself is identical to a regular forum post from a regular forum member...

Actually I just realized that's not true. it is possible to serve a single app via kasmvnc. It's still web based though.

It's quite fast, I recommend you try it.

https://docs.linuxserver.io/images/docker-webtop/ -- these are all in one docker containers that include kasmvnc and some apps, but you can also deploy kasmvnc independently.

KasmVNC is basically a completely different solution. It's browser based, has authentication (although regular vnc does as well), and they've made significant improvements to performance by using libjpeg-turbo instead of the normal image libraries.

When using the docker containers (e.g. the webtop linuxservio oned), I noticed no lag for non-gpu accelerated sessions over the internet.

Edit: although it's not your definition of rootless though.

Kasmvnc?

if one needs to run a containerised service

Can you elaborate what you mean by this? Because if a service is not packaged in Nixos, you won't be able to run it in a Nixos container either. Well, you can, but you would have to package/setup it yourself.

It actually is a language issue.

Although rust can dynamically link with C/C++ libraries, it cannot dynamically link with other Rust libraries. Instead, they are statically compiled into the binary itself.

But the GPL interacts differently with static linking than with dynamic. If you make a static binary with a GPL library or GPL code, your program must be GPL. If you dynamically link a GPL library, you're program doesn't have to be GPL. It's partially because of this, that the vast majority of Rust programs and libraries are permissively licensed — to make a GPL licensed rust library would mean it would see much less use than a GPL licensed C library, because corporations wouldn't be able to extend proprietary code off of it — not that I care about that, but the library makers often do.

https://en.wikipedia.org/wiki/GNU_General_Public_License#Libraries — it's complicated.

EDIT: Nvm I'm wrong. Rust does allow dynamic linking

Hmmmm. But it seems that people really like to compile static rust binaries, however, due to their portability across Linux distros.

EDIT2: Upon further research it seems that Rust's dynamic linking implementation lacks a "stable ABI" as compared to other languages such as Swift or C. So I guess we are back to "it is a language issue". Well thankfully this seems easier to fix than "Yeah Rust doesn't support dynamic linking at all."

Edit3: Nvm, I'm very, very wrong. The GPL does require programs using GPL libraries, even dynamically linked, be GPL. It's the LGPL that doesn't.

Openstack cluster!

curl -fsSL https://soar.qaidvoid.dev/install.sh | sh

I hate this, but I've mentioned before in the other threads related to this that I make an exception for package managers due to their ability to install packages themselves.

Am I just supposed to not distribute my software? And don’t say “distros will do it” because that’s clearly a shit non-solution. No distro has made a package for any of the software I’ve written.

Systems that protect people mean bureaucracy. And bureaucracy means slowness. It means many niche libraries or programs won't get packaged. It means that it won't get updated to the latest version immediately either, even if they receive security updates.

But as a consequence of these systems, Debian 12 remained entirely untouched by the XZ backdoor, when almost every other distribution was hit. That's a pretty big deal.

As a consequence of a lack of these systems, many Windows programs are still floating around with vulnerable versions of curl, having included the software into their "package" but never bothering to update it.

I care more about the security of the users than the feelings of the developers. It's that simple. Developers are a tiny fraction of total computer users. The needs of the many outweigh the wants of the few.

t’s especially bad for software engineers who are developing applications that need on a non-security big fix or new feature

This is what they tell themselves. That they need that fix. So then developers get themselves unstable packages — but wait! If they update just one version further, then compatibility will with something broken, and that requires work to fix.

So what happens is they pin and/or vendor dependencies, and don't update them, even for security updates. I find this quite concerning. For example, Rustdesk, a popular rust based remote desktop software. Here's a quick audit of their libraries using cargo-audit:

[nix-shell:~/vscode/test/rustdesk]$ cargo-audit audit
    Fetching advisory database from `https://github.com/RustSec/advisory-db.git`
      Loaded 742 security advisories (from /home/moonpie/.cargo/advisory-db)
    Updating crates.io index
warning: couldn't update crates.io index: registry: No such file or directory (os error 2)
    Scanning Cargo.lock for vulnerabilities (825 crate dependencies)
Crate:     idna
Version:   0.5.0
Title:     `idna` accepts Punycode labels that do not produce any non-ASCII when decoded
Date:      2024-12-09
ID:        RUSTSEC-2024-0421
URL:       https://rustsec.org/advisories/RUSTSEC-2024-0421

Crate:     libgit2-sys
Version:   0.14.2+1.5.1
Title:     Memory corruption, denial of service, and arbitrary code execution in libgit2
Date:      2024-02-06
ID:        RUSTSEC-2024-0013
URL:       https://rustsec.org/advisories/RUSTSEC-2024-0013
Severity:  8.6 (high)
Solution:  Upgrade to >=0.16.2

Crate:     openssl
Version:   0.10.68
Title:     ssl::select_next_proto use after free
Date:      2025-02-02
ID:        RUSTSEC-2025-0004
URL:       https://rustsec.org/advisories/RUSTSEC-2025-0004
Solution:  Upgrade to >=0.10.70

Crate:     protobuf
Version:   3.5.0
Title:     Crash due to uncontrolled recursion in protobuf crate
Date:      2024-12-12
ID:        RUSTSEC-2024-0437
URL:       https://rustsec.org/advisories/RUSTSEC-2024-0437
Solution:  Upgrade to >=3.7.2

Crate:     ring
Version:   0.17.8
Title:     Some AES functions may panic when overflow checking is enabled.
Date:      2025-03-06
ID:        RUSTSEC-2025-0009
URL:       https://rustsec.org/advisories/RUSTSEC-2025-0009
Solution:  Upgrade to >=0.17.12

Crate:     time
Version:   0.1.45
Title:     Potential segfault in the time crate
Date:      2020-11-18
ID:        RUSTSEC-2020-0071
URL:       https://rustsec.org/advisories/RUSTSEC-2020-0071
Severity:  6.2 (medium)
Solution:  Upgrade to >=0.2.23

Crate:     atk
Version:   0.18.0
Warning:   unmaintained
Title:     gtk-rs GTK3 bindings - no longer maintained
Date:      2024-03-04
ID:        RUSTSEC-2024-0413
URL:       https://rustsec.org/advisories/RUSTSEC-2024-0413


Crate:     atk-sys
Version:   0.18.0
Warning:   unmaintained
Title:     gtk-rs GTK3 bindings - no longer maintained
Date:      2024-03-04
ID:        RUSTSEC-2024-0416
URL:       https://rustsec.org/advisories/RUSTSEC-2024-0416

I also checked rustscan and found similar issues.

I've pruned the dependency tree and some other unmaintained package issues, but some of these CVE's are bad. Stuff like this is why I don't trust developers to make packages, they get lazy and sloppy at the cost of security. On the other hand, stable release distributions inflict security upgrades on everybody, which is good.

Yeah, I got to thinking about this more after I posted, and it’s a horrible idea. It’d guarantee system updates break user installs, and the only way it couldn’t were if system installs knew about user installs and also

???. This is very incorrect. I don't know where to start. If a package manager manages it's own dependencies/libraries, like nix portable installs, or is a static binary (e.g: soar), then system installs will not interfere with the "user" package manager at all. You could also use something like launchd (mac) or systemd users services (linux) to update these packages with user level privileges, in the user's home directory.

Also, I don't know where you got the idea that flatpaks manage "system level" software.

It all drives me back to the realization that the best solution is statically compiled binaries, as produced by Go, Rust, Zig, Nim, V.

I dislike these because they commonly also come with version pinning and vendoring dependencies. But you should check out Soar and it's repository. It also packages appimages, and "flatimages", which seem to be similar to flatpaks but closer to appimages in distribution.