Quarto has theming via several built in bootstrap themes.
Quarto is written in javascript.
Also, it has no template engine/templating. I have a nasty hack where I write python code blocks (vua quarto's ability to execute code blocks) to output markdown that can be remdered to both html and pdf, which is pretty unique. But this is probably not what most people making a website want.
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.
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.
A viable way to install something that works on all Linux distros (and Mac!), and doesn’t require root.
Nix portable installations, Soar.
The reason people use curl | bash is precisely so they don’t have to faff around making a gazillion packages.
Developers shouldn't be making packages. They do things like vendor and pin dependencies, which lead to security and stability issues later down the line. See my other comment where I do a quick look at some of these issues.
https://github.com/iorate/ublacklist
I use this, and there exist big lists of sites to block on github.
Doesn't fedora use zram by default nowadays?
Fun fact: you don't need to add the nixpkgs channel for the determinate systems installer, even when using channel commands or other things since it adds an option to your nix.conf to reference the nix flake for nixpkgs.
I don't know how to update this flake though.
Yes and no:
I use code-oss provided by the arch repos and it seems to automatically hook into thia. There is probably some way to add that to vscodium.
The chances I am going to manage a linux distro without systemd are low, but some systems (arch for example) don't have cron out of the box.
Not that big of a deal since it's easy to translate them all, but that's one of the reasons why I default to systemd/timer units.
I disagreed particularly with:
Furthermore, F-Droid doesn’t enforce a minimum target SDK
While yes, this may be a bad thing for some, certain apps, like termux (terminal emulator, even lets you make a linux chroot, some ppl play games using wine in it) only work properly on sdk's older than a certain version, since newer versions can be somewhat locked down.
I don't want to say that that article is "google good, f droid bad", but that's what a lot of what it's points are. It completely neglects to mention the downsides of google's various security models, especially for a foss community like this one. App bundles, for instance, are secure yes. But they are also an advanced form of drm (at least when made by google), must be compiled server side for each device, and other things that make them not work for the foss community.
And criticizing f Droid because it has multiple repos? That criticism is completely incompatible with the common FLOSS ideas that things should be less centralized.
Don't get me wrong, some of the points it brings up are valid, but they are biased, only focusing on on one side.
And I also don't feel the need to be alarmed by these points. What does it matter that google signs everything (in a supposedly better way) when "everything" includes malware?
As usual, no app or product can replace human discernment. Security is a process, not a product.
Alright, this is gonna be long.
Firstly, yes, different static site generators have different templating langauges. But just like normal programming languages, it is easy to transition from one templating langauge to another. If you take a look at the syntax:
Not drastically different, but reading the docs, they are all similar enough, and easy to learn.
I wouldn't call go's templating language "esoteric", but it should be noted that jinja2 is has other uses, most notably it is the templating engine that Ansible uses.
As for the docs... This could probably be a blog post by itself.
Firstly, take a look at this website: https://killedbygoogle.com/ . Google has created and then killed 296 projects, many of which were actively used and working. Why?
This is because, internally at Google, you get promoted if you either A: write software, or B: add more features to software. So what happens is people write software, get promoted, and then realize they don't get paid more if they actually maintain that software, so they just kill it. Also, they forget to write documentation (because it doesn't pay more or get you promoted).
Hugo, is by a Google Engineer, and it shows (or at least, it used to). Software by Google has two distinct characteristics (actually 3 if we count being written in Go).
But, "being poorly documented" is not a permanent fixture of this software, but instead something that mostly persists for as long as it's Google software. Often, these projects get "adopted" by the wider community, who fixes up their documentation. Looking at hugo's docs, it doesn't seem be nightmarishly bad, especially for the core, main set of features. Like the setup docs appear to be clear (although a more complex process than alternatives).
But like, for search options: https://gohugo.io/tools/search/ . That google software pattern continues. There are like 10 options on the page, and no docs from hugo on their usage/installation lol.
Anyway, I would recommend eithier Pelican or Jekyll, given your requirements. Because everything you write is in markdown, it will be fairly easy to move from one static site generator to another, even if you are dissatisfied.
Also, kinda sorta relevant:
(source)
But the point I'm trying to make is the same. Don't agonize over selecting the perfect static site generator.