Canadian software engineer living in Europe.
Kubernetes. For a homelab, the stripped-down k3s is fantastic and surprisingly easy to get going.
Once you’ve got Kubernetes set up, you can lean on all the many tools already out there for things like deploying complex projects (Helm) and monitoring (Prometheus/Grafana). OpenLens is a nice piece of software you can use to monitor and control your cluster too, as is k9s.
I’ve had Gentoo (and later, Arch) on my Surface Pro 3 for a decade. It’s fully supported, touch screen and all.
As this is a new project, have you considered hosting your code somewhere other than GitHub? Codeberg and GitLab are similarly user-friendly platforms without the many downsides of supporting Microsoft.
A platform that’s down 10% of the time and that now has a reputation of locking people out of their accounts without reason for weeks at a time cannot, under any definition of the word, be considered “stable”.
I just… don’t get it. This whole community, we’re supposed to be building stuff for ourselves and each other, and for some reason people keep going to bat for a company that demonstrably holds every one of us in contempt.
Just… stop using their shitty tools already.
Why hasn’t he migrated to something more stable?
Don’t be that guy.
I know it’s supposed to be a joke how a nerd will spend six hours writing a script to automate a 30second task but… it’s not really funny.
Working with less-experienced developers, I’m amazed at how slow everything is for them: No keyboard shortcuts, no automated scripts, just slow, plodding mouse-driven tinkering.
Automation, shortcuts, and scripting drive your ability to iterate and therefore learn.
Train your fingers, and spend those hours automating repetitive stuff. It’s worth it.
The aversion to using a GPL library is a red flag for me. It basically says: “we don’t want to grant our users the same rights we have”.
The following don’t seem to fit any of these (and they’re all excellent):
I used to get very upset by this, but I’ve taken great solace in seeing how their power and influence are waning.
I’d never heard of this list, so thanks for sharing. I have to say while some of the projects seem to have been included due to minor offences, I’m really disappointed in some of my favourite FOSS projects.
I didn’t understand what you meant by Joplin not being “fully FOSS”, so I went looking for the license. Is really quite strange. Basically they’ve used a “personal license” for some parts and the AGPL for the rest. That’s… annoying.
Every now and then I need to make a presentation, and LibreOffice Impress to Microsoft PowerPoint isn’t that good. I resort to Google Slides for now.
It may not be your thing, but personally I’ve had a lot of success with RevealJS. You just write HTML (or even Markdown) and it automatically builds your slides for you such that they run on any browser. You can make it as complicated or as simple as you like (I’ve done some wild stuff with CSS) and everything can be versioned in git and published to anywhere that supports static files.
Here’s a reasonably professional-looking presentation I occasionally give about Kubernetes if you’re interested.
Are you using GNOME? If so, I remember there being an extension for that.
You might like Krita a little more. It’s far more powerful than Paint, but its interface is very familiar.
I would be less concerned about the GPU driver and more about the entire distro. Like most distros, Ubuntu has a release cycle where versions of everything are deprecated over time in favour of newer ones, and to expect that the entire OS will be fully supported in 10 years may be asking a bit much (I’m not sure if even their LTS release goes that far).
On top of that, Ubuntu could go bankrupt or get bought out, or simply enshittify (more than it already has) in that time. Expecting Ubuntu specifically to be supported on your laptop in ten years is anyone’s guess.
However, what you can be reasonably sure of is that Linux will continue to support your system, GPU and all, for a very long time. I heard a kernel developer once say that due to the kernel’s modular design, there’s support in there for stuff just one or two people in the whole world use.
As someone else has already pointed out, FOSS support for hardware generally gets better over time, and a GTX video card is ubiquitous. There’s going to be a hell of a lot of those floating around on laptops, servers, and homelabs for a lot more than ten years.
You just might not be able to stick with Ubuntu. The older the hardware, the more you might have to lean toward the more technical distros that make it easy to customise the kernel or that favour old hardware. I like Gentoo for this job, but even Ubuntu or Debian have paths to do compile your own kernel for example.
Buy two 4tb extern drives. Copy your photos onto both. Leave on at your mom’s house in a closet. Leave the other in a locker at work or a safety deposit box.
No monthly fees, no techbro cloud capitalists.
I’ve used FluxCD in the past and have looked into ArgoCD, but honestly, I’ve not seen any big benefit from either to be honest. I use k8s both at home and at work, and in both cases, we do “imperative” deploys: you run
helm install ...either directly or via the CI and stuff is deployed.So for example at my last job, our GitLab CI just had a section triggered exclusively for merges into
masterthat ranhelm install ...for all three environments. We had threevalues.yamlfiles, one for each environment, and when we wanted to deploy a new version, the process was:1.2.3) and push it to the repo. This would trigger a build and push the resulting image into the container registry.1.2.3todevelopmentbut not yet tostagingorproduction, then thetag:value in each of the environment files would look like this:k8s/chart/environments/development.yaml:tag: 1.2.3k8s/chart/environments/staging.yaml:tag: 1.2.2k8s/chart/environments/production.yaml:tag: 1.2.2Once that change is pushed, the CI will automatically apply it with
helm install ...and make sure that all three environments are what they’re supposed to be.As for dependent services, that should all be in your Helm chart so they’re stood up and torn down together. The specific case you mention about “Service A” being dependent on “Service B” but stood up before “Service B” is ready is a classic problem, but easily solved:
The dependent service (“A” in this case) should have an entrypoint that checks for everything else before starting. Here’s what I’m using right now in a project:
#!/bin/sh while ! nc -z postgres 5432; do echo "Waiting for postgres..." sleep 0.1 done echo "PostgreSQL started" touch /tmp/ready exec "$@"I’ve even got some code that checks that all the Django migrations have run first for the same situation. The Kubernetes philosophy is that any container should be able to die at any time and be eventually be brought back up and that every container needs to be prepared for this. Typically this means that your containers should operate on the basis of “if I can’t work, die, and hope the problem is solved by the time Kubernetes redeploys me”.