https://opensource.google/documentation/reference/using/agpl-policy/

AGPL policy: Don't use.

Yes. Firstly, it's about release cycles. Centos Stream is a rolling release distro (although it rolls very, very slowly). But what this means, is that there isn't a true guarantee of application/ABI/API compatibility between current versions of Centos Stream and future versions.

In constrast to this, Centos 8 and previous were complete clones of Red Hat Enterprise Linux, which was a stable release distro. During the 10 year lifecycle of each RHEL release, there was a guarantee certain application/ABI/API compatibility not changing, which is what stability in the Linux/software world is defined as.

Centos 8 was a free alternative, for institutions unwilling, or unable to pay for RHEL stable releases. But, with the death of Centos, an alternative was needed. Alma Linux, Rocky Linux, and Scientific Linux (designed for labs and universities), were rebuilds of RHEL. This meant that, they would take RHEL's open source code, and recompile it and distribute it in a way that guaranteed application/ABI/API compatibility with RHEL, for the same lifecycle of a RHEL release.

So Alma Linux and Rocky Linux fill that gap... but recently, RHEL said that they are adjusting policies to make it much harder for people to make rebuilds (likely targeting Oracle Linux, which is a RHEL rebuild), but this change may affect Alma and Rocky as well.

Rocky said they were going to keep bug-for-bug compatibility, like they used to, but Alma says they are going to do something different. Although they still intend to be ABI compatible, Alma has decided to make some changes to the base system, such as reimplimenting and continuing to support things that Red Hat saw unfit to continue existing in RHEL. One example of this is SPICE, which is a graphics protocol used for low latency display of virtual machines. It had many usecases, and I am very excited to see it back in a distro in the Red Hat ecosystem.

The solution to what you want is not to analyze the code projects automagically, but rather to run them in a container/virtual machine. Running them in an environment which restricts what they can access limits the harm an intentional

or accidental bug can do.

There is no way to automatically analyze code for malice, or bugs with 100% reliability.

PhobosLabs

This site has a few high quality browser games. The one I come back to is X Type, a bullet hell shoot-em up that has ever expanding enemy ship sizes, and never ends. It gets hard fast.

I also like Xibalba, which is a Doom/Wolfenstein style game playable in the browser.

The creator also did a rewrite of quake in 13 kb of javascript

Spent

A short questionaire game that demonstrates the difficulties of poverty.

Code Romantic

Learn the pleasures of loving another human, and the pain of being a programmer — at the same time!

You could say the same thing about sudo. Sudo's codebase is massive, compared to alternatives like doas, but it comes with many features doas does not have, like being able to ask a remote LDAP server if a user will be able to escalate.

I find it absurd that we have just simply accepted the idea of a setuid binary with built in networking code, as our primary admin escalation tool. 100,000+ lines of C code, code that has had multiple buffer overflow exploits*, in a setuid binary, just for temporary admin privileges. Does that seem necessary to you?

Polkit provides an alternative to that. If you don't need the features, then fine, you don't have to use run0 — but then you can't use sudo without being a hypocrite. No longer do I have to have rely on a setuid binary that tries to do everything in one program when I really need sudo's features, instead polkit handles authentication (including asking remote resources if an action is okay), and run0 handles actual escalation.

In another comment in this thread, you mention sudo being lightweight — which is outright false. Compared to doas or su, it's extremely heavyweight, and with that complexity comes more risk of vulnerabilities. You also mention pkexec, for executing with polkit, but pkexec is also setuid, and has many of the same pitfalls.

*Buffer overflow exploits in sudo:

1. https://arstechnica.com/information-technology/2020/02/serious-flaw-that-lurked-in-sudo-for-9-years-finally-gets-a-patch/
2. https://blog.qualys.com/vulnerabilities-threat-research/2021/01/26/cve-2021-3156-heap-based-buffer-overflow-in-sudo-baron-samedit

It's a shame the price you pay for that is no crossplatform support.

If you have a little bit of server management know-how, you can set up https://geysermc.org/, which allows for crossplay between bedrock and java on a java server.

The benefit of docker is portability. You can run software anywhere. Rather than going through all this pain of installing and managing systemd services, you can just run a docker container, often in only one command. Docker also handles things like setting environment variables, which are sometimes used by apps as a an alternative for, or even replacement for settings filed, like in the lemmy docker example: https://github.com/LemmyNet/lemmy/blob/main/docker/docker-compose.yml

Docker succeeds where java failed, but in a language agnostic way.

And I disagree with the author's point about disliking docker-only apps, for two main reasons. One, it isn't the developers responsibility to package things for every system, and two, docker containers are mostly self documenting, being very close to simply a shell script. I almost always look at dockerfiles, and I have only seen one or two that are not simple to extract to make them run outside docker.

For example, the lemmy docker image: https://github.com/LemmyNet/lemmy/blob/main/docker/Dockerfile

The author acts like it's some advanced witchcraft or something, but it's just using rust to compile stuff on an debian based system. Every command used to build lemmy is right there. Then, you can look at the environment variables set in the docker compose, and set them in a systemd service or something.

How do I tag people on lemmy?

u/tony

I'm in the max server limit, 100 right now, and many of those are people who treat discord as github, which is so annoying (but many projects are of questionable legality, like Dan's palace which makes and distributes completed android and vita ports of other games for free).

One time I got excited since there was announcement for the half life 2 android source port discord. I thought it was a big update or maybe a new game, but what I saw was something like:

the memes channel is for memes, not child porn

It's just discord that has these issues. Matrix or IRC don't have these problems. Discord just creates a kind of culture that fosters this stuff.

Incorrect, from wikipedia:

The available research indicates that the brain structure of androphilic trans women with early-onset gender dysphoria is closer to that of cisgender women than that of cisgender men.[3] It also reports that gynephilic trans women differ from both cisgender female and male controls in non-dimorphic brain areas

Aka: Trans women may have been born with the body of a man, but they were born with the brain of a woman.

https://en.m.wikipedia.org/wiki/Causes_of_gender_incongruence#:~:text=The%20available%20research%20indicates%20that,in%20non%2Ddimorphic%20brain%20areas.

Once federation gets added to one of the FOSS, self hosted alternatives, I'll probably switch. I'll mirror stuff to github probably, for resume/recruiter purposes, but the CI/CD, website deployment, and main development will happen on whatever alternative I chose.