For maintenance I would recommend a ticketing system instead of forgejo:

https://selfh.st/apps/?search=ticket

There are a few options and they probably all work better than a git issue tracker.

Another thing I would recommend is to have centralized accounts via an identity provider. People have one username and password they can use to log into all the services, and you can reset/signup them to all connected services by managing the identity provider app.

There are a few options for this as well but I’m on my phone some imma just list the three that I find most promising for your usecase: kanidm, voidauth, authentik.

https://home.robusta.dev/blog/stop-using-cpu-limits

Okay, it’s actually more complex than that. Because on self managed nodes, kubernetes is not the only thing that’s running, so it can make sense to set limits for other non kubernetes workloads hosted on those nodes. And memory is a bit different from CPU. You will have to do some testing and YMMV but just keep the difference between requests and limits in mind.

But my suggestion would be to try to see if you can get away with only setting requests, or with setting high very high limits. See: https://kubernetes.io/docs/tasks/configure-pod-container/assign-memory-resource/#if-you-do-not-specify-a-memory-limit

In order for them not to be OOM Killed, you have to set the memory requests for them above their highest spike, which means most of the time they’re only using like 25% or so of their memory allocation.

Are you sure? Only limits should limit the total memory usage of a pod? Requests should happily let pods use more memory than the request size.

One thing I am curious about is if your pods actually need that much memory. I have heard (horror) stories, where people had an application in Kubernetes with a memory leak, so what they did instead of fixing the memory leak, was to just regularly kill pods and restart new ones that weren’t leaking yet. :/

To answer your actual question about memory optimization, no. Even google still “wastes” memory by having requests and limits higher than what pods usually use. It is very difficult to prune and be ultra efficient. If an outage due to OOM costs more than paying for more resources would, then people just resort to the latter.

There does exist a tool that does it. The creator posted about it on the fediverse. It only supported ubuntu at the time but looked extremely promising.

I cannot remember it’s name. :/

Maybe it’s linixify? But I remember seeing a post on lemmy with a youtube demo?

unless the SSD stopped working but then it is reasonable to expect it would no accept partitioning

This happened to me. It still showed up in kde’s partition manager (when I plugged the ssd into another computer), with the drive named as an error code.

My recommendation is meetup and a website for advertising purposes. Meetup is frustrating, yes, but at the same time it’s where I have found almost all the linux and tech groups near me.

Familiarity instead of compatibility.

This piece of documentation from forgejo, about how their actions are mostly github actions compatible is how I feel about this or similar endeavors.

I really like KDE, because it’s familiar enough to Windows users that they can just kinda use it. Many of the shortcuts are the same. But I’ve had a bad experience with things that try to emulate Windows more completely, because people begin to expect some windows idiosyncracy or some other thing to be there. And then they get frustrated when it’s not the same.

KDE manages to be “close enough”, which results in a better experience.

Yes. My high school used to do this. UDP blocked except for DNS to some specific servers, and probably some other needed things.

The backdoor of the xz utils program(s) was in the tarball release, but not the main source code:

https://en.wikipedia.org/wiki/XZ_Utils_backdoor

If debian had dodged the upstream tarball, then they wouldn’t have been affected by this.

Is this because of the xz utils thing? The backdoor was included into the tarball, but it wasn’t in the git repo.

By switching away from tarballs they pribably hope to prevent that, although this article doesn’t mention that. It’s possible this shift has been happening since before the xz utils.

Late reply but I also recommend going through flathub for screenwriting apps if you want more. I saw some options that looked pretty good, although many were proprietary.

https://intronetworks.cs.luc.edu/

I have a similar setup, and even though I am hosting git (forgejo), I use ssh as a git server for the source of truth that k8s reads.

This prevents an ouroboros dependency where flux is using the git repo from forgejo which is deployed by flux…

sandboxing is not the best practice on Linux… So I’m better off with Qubes than with Secureblue

No, no, no.

It’s no that sandboxing is the best practice, it’s just that attempting to “stack” linux sandboxes is mostly ineffective. If I run kvm inside xen, I get more security. If I run a linux container inside a linux container, I only get the benefit of one layer. But linux sandboxes are good practice.

I do agree that secureblue sucks, but I don’t understand your focus on Qubes. To elaborate on my criticisms let me explain, with a reply to this comment:

Many CVE’s for Xen were discovered and patched by the Qubes folks, so that’s a good thing…

If really, really care about security, it’s not enough to “find and patch CVE’s”. The architecture of the software must be organized in such a way that certain classes of vulnerabilities are impossible — so no CVE’s exist in the first place. Having a lack of separation between different privilege levels turns a normal bug into a critical security issue.

Xen having so many CVE’s shows that is has some clear architectural flaws, and that despite technically being a “microkernel”, the isolation between the components is not enough to prevent privilege isolation flaws.

Gvisor having very few CVE’s over it’s lifespan shows it has a better architecture. Same for OpenBSD — despite having a “monolithic” kernel, I would trust openbsd more in many cases (will elaborate later).

Now, let’s talk about threat model. Personally, I don’t really understand your fears in this thread. You visited a site, got literally jumpscared (not even phised), and are now looking at qubes? No actual exploit was done.

You need to understand that the sandboxing that browsers use is one of the most advanced in existence currently. Browser escapes are mostly impossible… mostly.

In addition, you need to know that excluding openbsd, gvisor, and a few other projects almost all other projects will have a regular outpouring of CVE’s at varying rates, depending on how well they are architectured.

Xen is one of those projects. Linux is one of those projects. Your browser is one of those projects. Although I consider Linux a tier below in security, I consider Xen and browsers to exist at a similar tier of security.

What I’m trying to say, is that any organization/entity that is keeping a browser sandbox escape, will most definitely have a Linux privilege escalation vulnerability, and will probably also have a Xen escape and escalation vulnerability.

The qube with the browser might get compromised, but dom0 would stay safely offline, that’s my ideal, not the utopic notion of never possibly getting attacked and hacked.

This is just false. Anybody who is able to do the very difficult task of compromising you through the browser will probably also be able to punch through Xen.

not the utopic notion of never possibly getting attacked and hacked.

This is true actually. Browser exploits are worth millions or even tens of millions of dollars. And they can only really be used a few times before someone catches them and reports them so that they are patched.

Why would someone spend tens of millions of dollars to compromise you? Do you have information worth millions of dollars on your computer? It’s not a “utopic notion”, it’s being realistic.

If you want maximum browser security, disable javascript use chromium on openbsd. Chromium has slightly stronger sandboxing than firefox, although chromium mostly outputs CVE’s at the same rate as firefox. Where it really shines, is when combined with Openbsd’s sandboxing (or grapheneos’ for phones).

Sure, you can run Xen under that setup. But there will be no benefit, you already have a stronger layer in front of Xen.

TLDR: Your entire security setup is only actually as strong as your strongest layer/shield. Adding more layers doesn’t really offer a benefit. But trying to add stronger layers is a waste of your time because you aren’t a target.

Proxmox is based on debian and uses debian under the hood…

to answer your first question, kind of. Gvisor (by google btw) uses the linux kernels sandboxing to sandbox the gvisor process itself.

Distrobox also uses the linux kernels sandboxing, which is how linux based containers work.

Due to issues with the attack surface of the linux’s kernels sandboxing components, the ability to create sandboxing or containers inside sandboxes or containers is usually restricted.

What this means is that to use gvisor inside docker/podman (distrobox) you must either loosen the (kinda nonexistent) distrobox sandbox, or you must disable gvisors sandboxing that it applies to itself. You lose the benefit, and you would be better off just using gvisor alone.

It’s complicated, but basically the linux’s kernels containers/sandboxing features can’t really be “stacked”.

Check out turbowarp, an ultra fast reimplementation of scratch.

I’ve seen games that only worked in turbowarp.

Custom editors are probably needed.

https://github.com/trelby/trelby ?

https://trelby.org/

Found here: https://wiki.archlinux.org/title/List_of_applications/Documents#Screenwriting

Kde’s spectacle (screenshot utility) does this by default now.

I don’t see any mention of games so far.

A minecraft server is always a good time with friends, and there are hundreds of other game servers you can self host.

Syd3, and gvisor, a similar project in go aren’t really sandboxes but instead user mode emulation of the linux kernel. I consider them more secure than virtual machines because code that programs run is not directly executed on your cpu.

Although syd3 doesn’t seem to emulate every syscall, only some, I know rhat gvisor does emulate every syscall.

If you compare CVE’s for gvisor and CVE’s for xen/kvm, you’ll see that they are worlds apart.

Xen has 25 pages: https://app.opencve.io/cve/?vendor=xen

Gvisor has 1: https://app.opencve.io/cve/?q=gvisor

Now, gvisor is a much newer product, but it is still a full 7 years old compared to xen’s 22 years of history. For something that is a third of the age, it has 1/25th of the cve’s.

There is a very real argument to be made that the hardened openbsd kernel, when combined with openbsd’s sandboxing, is more secure than xen, which you brought up.