stasge

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.

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.

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"?

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.