Docker is not a replacement though, you can't use Docker as a VM, not without workarounds, limitations and caveats.

Lima give you a VM.

Vagrantfile gives you a repeatable and portable environment with just a few lines of configuration. Product demo? Pre-configured local Kubernetes? Clean build environment? Pre-cooked clean setups for 3rd party software projects? Everything is possible with just vagrant up -> vagrant ssh -> vagrant halt/destroy. There is no simple alternative.

I think I understand why, I used Vagrant for many years and this was my evolution:

* Vagrant for everything: VM provisioning(always local), os dependencies, app dependencies and the apps themselves was all Vagrant.

* Vagrant for VM provisioning and OS dependencies only. docker-compose for the rest

* Vagrant for VM provisioning, Rancher 1.6-ish for the rest

* Vagrant for VM provisioning and K3S for the rest.

* either k3s or docker-compose with no VM

so towards the end it was easy to replace Vagrant with whatever provisioned a VM

It's like Docker without public registries, nobody is going to use it

The problem is not Kubernetes but how it's treated. From its inception I've been seeing two anti-patterns: treating it as a platform (and being frustrated for Kubernetes not meeting expectations) and treating it as a product or part of a product (investing heavily into its customization and making it a dependency). Neither is practical unless you are building a platform and it is your product. Otherwise it should be viewed as an OS and treated as a commodity. You create a single big VM with MicroK8s per project (zero-ops vanilla Kubernetes) and make no dependency on how exactly Kubernetes is setup. This way you can run the same setup locally and in a data center. If ever needed your app could be moved to any cloud as long as that cloud meets basic prerequisites (like presence of persistent storage or load balancer). The best part is Kubernetes (unlike traditional OS) is API driven and your apps could be nicely packaged and managed using Terraform/OpenTofu or similar tooling.

My commute to work is quite long but there is no "sitting" in Tokyo's trains in mornings/evenings so I program on a smartphone. Yes, it's not impossible but it takes time to get used to it.

Would you mind sharing a bit more about how you make it work? Do you have an app? or are you just using the notepad on your phone?

have you ever considered a nanote from donki? I've been using one as a paired terminal and with the right os (debian, no GUI) it stays cool enough and gets good battery, same with the gpd handhelds

I would go for some affordable AR glasses + a one-hand chord keyboard. No need to hold a device in one hand and operate it with another, while standing awkwardly bent down.

I generally just thumb-type on it with the hinge bent at 180°. I have a colleauge who tried the meta AR glasses and found the display smudgey with his 20/20 vision and my quest 3 I found very screen door-y, though I will admit I liked the apple vision pro's display, I have a fair bit of pessimism about the field as a whole atm, but would like to be proven wrong

There is a low hanging fruit in making GitHub Actions more secure (anyone from GitHub here?):

  - Forbid (or at least warn about) shell interpolation in composite actions and guide to using environment variables instead
  - Warn unless all external actions are pinned by git commit (with customizable exceptions)
  - Warn unless all used docker images are pinned by digests

Time for a new term "Synthocial Engineering"?

While I agree that GitHub Actions could be more "secure and safe" by default most gaps are easy enough to fill. With https://github.com/marketplace/actions/check-actions you can ensure timeouts, permissions and version pinning. With https://registry.terraform.io/modules/giner/repo/github you can manage all repos together with workflows.

Unfortunately Mozilla has greatly contributed to this. At the time when Firefox had a good user share Mozilla instead of promoting RSS has decided to remove RSS/Atom feed icon from the address bar because of their telemetry showing rare usage. While it is still possible to install the icon as well as live bookmarks as add-on to do that one needs to know of their existence.

Reading the comments makes me wonder why where perception of Ruby that it is complex or hard to learn is coming from. Let's talk about just language without external libraries, package management or context of specific software.

I'm using both Ruby and Python for tooling (so there is neither Web nor ML context. Neither meta-programming). When it comes to Ruby I learn one thing and safely extrapolate, i.e. you don't need to learn all of the language to be able to use it. With Python I've had to come to the docs many times to understand how a particular thing works and I keep finding ways to shoot in my foot. This includes very basic stuff like variable scoping (global, class, instance or local) or type non-obvious type conversion (in Ruby only nil and false are treated as false in conditional expressions, while in Python this includes empty string, empty list, empty dictionary and so on).

When it comes to readability in Ruby it is natural to do data processing by "pipelining", e.g. you don't need to do f1(f2(f3(f4(data)))) (which is often the case in Python) and instead you can do data.f1.f2.f3.f4 which is easier to read. Classes, objects, inheritance work and feel a lot more obvious. Ruby allows to be concise without sacrificing (for example "a = 5 if seta == true"). Overall Ruby allows to write more readable code than Python.