brie

Termux + Termux-X11 is another possibility.

Although you have good intentions, writing your own license is probably not a good idea without adequate legal advice/background.

The linked article does provide calculations. The main assumption for such a short prediction appears to be that the rate of energy consumption will continue to grow exponentially, which to me seems unsustainable regardless of the production method.

As far as I can tell, the main problem with such a fork is that it must be maintained. A fork wont survive if nobody has the time, interest, and skill to keep it working, especially since with Lemmy there is compatibility with other instances to be considered.

However, even without a fork of Lemmy itself, there are things that can be independently developed. Since Lemmy has an API, people can and have implemented features such as infinite scrolling in their own clients or forks of the official UI.

Sample size of one, but when I used Brave without enabling Brave Rewards, I didn't get ads. The Brave Rewards page also seems to suggest it is supposed to be opt-in.

since we're on the FOSS community, I'd recommend using Ungoogled Chromium since Vivaldi isn't fully open source.

To be fair, they're opt-in. They won't show if you don't use the BAT wallet.

Very late, but C solution using fib: Git

#include 
#include 
#include 

size_t fib(size_t n)
{
	/* n=93 is the last fib(n) that fits in u64. */
	static size_t cache[94] = { 0, 1 };
	static size_t top_valid = 1;
	size_t a, b;

	if (top_valid >= n) {
		return cache[n];
	} else if (n >= sizeof(cache) / sizeof(*cache)) {
		fputs("Fib overflow\n", stderr);
		exit(EXIT_FAILURE);
	}

	a = cache[top_valid - 1];
	b = cache[top_valid];
	for (; top_valid < n; top_valid += 2) {
		a = cache[top_valid + 1] = a + b;
		b = cache[top_valid + 2] = a + b;
	}

	return cache[n];
}

int main(int argc, char **argv)
{
	char *p, c;
	size_t combos = 1;
	int digits = 0;
	

	if (argc != 2) {
		fputs("Bad invocation.\n", stderr);
	}

	if (!*(p = argv[1])) {
		goto done;
	}

	for (;;) {
		c = *++p;
		if (c < '0' || c > '9') {
			combos *= fib(digits);
			digits = 0;
			if (!c) {
				break;
			}
		} else {
			digits++;
		}
	}

done:
	printf("%zu\n", combos);

	return 0;
}

Zig would probably be a good language for a solution if there is a known maximum number of combinations, since it has large fixed-width types and comptime.

The MPL allows for it as far as I can tell, its just fairly complicated since the MPL would still apply at the file-level for all existing files.

JavaScript (~~Deno~~Bun): bun easy.js aaabbhhhh33aaa

Golf attempt using RegExp to match homogenous substrings.

console.log(Deno.args[0].replace(/(.)\1*/g,a=>a[0]+(a.length+'')))

Slightly optimised by removing the frivolous conversion to string. I also made a somewhat silly opitmisation of using Bun.argv instead of Deno.args to save a character.

console.log(Bun.argv[2].replace(/(.)\1*/g,a=>a[0]+a.length))

For ADB, I can recommend Shizuku (available on F-Droid) with aShell (for adb shell commands) and Amarok (for disabling apps). It uses wireless debugging to allow the device to run adb commands on itself.

The Temple examples look very nice; the Builder ones to my eye look quite cluttered in comparison, which I'm guessing is due to differences in syntax between their respective languages.

I tink the main downside of templating in general is that it ends up making interfacing with JavaScript and plain HTML harder, compared to CustomElementRegistry based components.