Fuck off and give me the fiber that was promised and paid for decades ago.

In my experience often detriment. Most of the images for projects that I have been encountering as of late - hell, most Dockerfiles that I’ve been encountering - have hardware-specific config and packages. I just want a Dockerfile or maybe a docker-compose.yaml that is hardware neutral by default and doesn’t use the shitty throttled Dockerhub for its base image.

#!/bin/bash
# Build image and push to registry
docker build -t myproj:latest . && docker push myproj:latest

JFC. What is wrong with people? I just want to write code that works, is interesting, and doesn’t have memory problems.

any change to shell scripts that isn’t posix compatible brings opinionated people out the woodwork.

Yo. Did I hear someone breaking POSIX-compatability over here?

I, for one, really love HTTP over

apache2.conf
conf-available/
conf-enabled/
mods-available/
mods-enabled/
sites-available/
sites-enabled/
envvars
magic
ports.conf
sites-available/
sites-enabled/

First, I would like to give you some major props. Installing Arch, in itself, is a big deal. It is not a beginner-friendly distro. It is a very power-user friendly distro and has an incredible wiki that is helpful, at least to some degree, for many distros.

For a beginner distro, I would recommend Linux Mint for its easy transition and great focus on user experiences or Bazzite if you really want to install and get gaming.

When taking drivers in Linux, most are provided as either kernel modules (integrated into the kernel, so you don’t have to worry about installing anything) or packaged for the distro, in which case, once installed via package manager, they’ll auto-update whenever you update system packages. They are so much easier to deal with than Windows drivers (for the end user). For example, to use a Wacom drawing tablet, all one has to do is plug it in.

It’s really not just that it is/was cheaper. There are cases where, all costs considered, it was actually measurably more expensive. The main reason for off-shoring is purely ideological. Amercan capital has nothing but disdain for workers and hatred for organized labor. Off-shoring was intended to crush unions, while giving a temporarily lower price to goods to prevent the populace from understanding how much they were getting screwed.

Chip production is a highly specialized field, where workers could readily demand concessions from capital, were they on anything resembling stable ground. That was not too be allowed.

It’s like they really don’t want me to use their pro-Nazi LLM, that I already didn’t want to use on account of the tweaks that they made to make it support nazism.

It is an unfortunately shared initialism. Cognitive Behavioral Therapy.

Appinages are fine. Needing to apply changes as patchsets rather than just building normally sucks. Especially in deb and rpm distros.

Fortunately, it looks like that was done already with Swanstation, which also has many more contributors.

Yes. The license doesn’t technically appear to forbid forking, just sharing the fork.

I have some issues with flatpak, myself, but that mainly stems from having trouble finding documentation to clear up how to properly use extensions and non-standard dependencies that are easy to do with OCI images.

Ex. I had a really hard time trying to get Vega Strike built as a flatpak.

Yeah… That’s pretty terrible. I was meaning packaging patchsets for other distros. Hopefully the GPL-preserving fork is better.

Yeah… But then it sucks for anyone not running Arch (btw) or derivative distros. I really don’t have a dog in this merge conflict but really would feel bad for any packager maintainers.

Would have to go back to before the license change in September 2024. The current license basically forbids forks, from my reading.

Yeah. That’s a pretty shitty license to move to for endusers and others. Disallowing derivatives, etc. is within their rights but, really a dick move but, considering this commit message, not surprising.

As I mentioned in other comments, I am a noob when it comes to web-sec; please forgive what may be dumb questions.

There’s nothing to forgive. Asking questions and being curious is how you learn this stuff.

Is it really just permission rights “over-exposure” issue?

From what I’ve read, it’s more fundamental than that. It’s a basic architecture issue. The datastore was publicly accessible, which it should never be. If they had it setup according to best practices, with an API to proxy access and auth, the datastore’s permissions would be of minimal consequence, unless their network was compromised (still best practice to secure it and approach with a zero-trust mindset).

Or does one need to also encrypt and then decrypt the data itself that must be sent to a database?

Generally, cloud datastores handle encryption/decryption transparently, as long as the account accessing data has authorization to use the key. They probably also didn’t have encryption setup.

Also, if you have time, recommend any links to web/cloud/SaaS security best practices “for dummies”?

Here are some more resources:

• https://cheatsheetseries.owasp.org/cheatsheets/Secure_Cloud_Architecture_Cheat_Sheet.html
• https://www.oreilly.com/library/view/security-architecture-for/9781098157760/
• https://www.oreilly.com/library/view/cloud-computing-security/9780429619649/
• Check Humble Bundle

I’d argue that it should not even be done in Dev. Dev, staging/testing, and prod environments should all be as close to one another as possible, especially for infra like datastores.