Looking through the commit graph for Omarchy is wild. It has 2000+ commits, most of which contain the type of intermediary work pushed into the trunk that you'd see from a jr who doesn't squash their local work

Also some gems like: https://github.com/basecamp/omarchy/commit/af72a45dbd4358bca...

> Remove non-existent vibe-code hallucinated options and clean up theme files

or https://github.com/basecamp/omarchy/commit/4fedfbe9f19303046...

There's also Omakub[0] which was sort of a precursor to Omarchy that gives users the `wget <some url> | bash` as a means of installation where the install script is a thin wrapper around another `eval $(wget <some url>` that then git clones a repository and executes a 3rd script.

That's definitely the kinds of patterns I'd expect some prolific software engineer to use and also encourage complete novices to Linux to be comfortable just piping arbitrary wgets into a shell

[0] https://omakub.org/

"dead simple" really depends on what you're targeting and how. If you're targeting a cloud deployment on hardware you don't control or that's running with multiple instances/replicas, OTEL makes that pretty simple because you get a lot for free in the way of tracking instances/correlation ids, etc.

If you wanted "dead simple" text-based logging in a situation where a service is deployed in multiple places you'd end up writing a lot of fluff to get the same log correlation abilities that most OTEL drivers provide (if you can even ship your logs off the compute to begin with)

Which again comes back to the "maybe the framework isn't for you" if you're building an application that's a monolith deployed on a single VPC somewhere. But situations where you're working on something distributed or replicated, OTEL is pretty simple to use compared to past vendor-specific alternatives

I don't really know anything about self-hosting Next apps - but if you're deploying to k8s, it's not really that difficult or far-fetched to run an otel collector sidecar for your applications. It's already common to run some kind of prometheus scraper or other service to collect logs/metrics from your services but instead of having to have different collection methods for APM vs logs vs traces you can have it all aggregated in one place using OTLP format

That doesn't really mean it's heavyweight though; an extra layer, sure (but I don't even really agree that it's complex - you set it up once and then mostly just log the same way you would with any other).

You can still log to a text file if you want to run locally, but for something like next.js where you're intended to deploy production to some cloud somewhere (probably serverless) the option of _just_ writing to a text file doesn't really exist. So having OTEL as an ootb supported way to do o11y is much better than the alternative of getting sucked into some vendor-specific garbage like datadog or newrelic

What specifically is heavyweight about OTEL? At its core it's a standard for producing structured logs along with some standards for exporting/collection. The heaviness is really implementation-specific and can vary stack to stack

There's even a handler for monolog in PHP - they are not necessarily mutually exclusive

https://github.com/open-telemetry/opentelemetry-php/blob/mai...

> Why can’t logger().info() just work in a sensible way?

I think OTEL is pretty sensible for a vendor-free and if you want to have a console logger you can use the console exporter[0] for debug mode during local development. Also if Next is designed as a framework to make it easy to build production-grade apps, having a standardized way to implement o11y with OTEL is a worthwhile tradeoff?

If you view that as being overkill, perhaps you're not the target audience of the framework

[0] https://opentelemetry.io/docs/languages/js/exporters/#consol...

The Bitnami images and helm charts are just convenient repackaging of things that are already freely (gratis) available. There's nothing stopping you from still deploying Kafka or Redis, etc. into your k8s cluster without using the Bitnami helm chart or building your own charts.

I think that's the point of above of "now you have to do your job" There's an evaluation that takes place when choosing to use something as an engineer, and the writing should have been on the wall the moment that Broadcom bought Bitrock to start planning to reduce dependency on those things.

> An e-bike that can even do 20mph comfortably is much closer to a moped than a bicycle

There are pedal assist ebikes hitting the market that are nearly indistinguishable from a road bicycle and weigh as much as a kitted out steel touring bike (i.e. ~35-40 lbs) and can comfortably do 20 mph.[0] I don't really think that's treading any sort of line of being close to a moped.

Also there are absolutely people riding analog bikes capable of having an average cadence of 15-20 mph who ride with reckless abandon on crowded mixed-used paths in cities - so maybe you don't do that, but there's a pretty large subset of cyclists who are doing that because biking is more of a sport activity than strictly pragmatic form of transportation. Bad bike path etiquette extends beyond ebikes

[0] ride1up is one brand making such bikes

Isn't it likely that newer projects licensing under GPL are also unlikely to be using GitHub and instead be using a platform like GitLab or Forgejo (or previously Gitea or something)?

This is basically the modern "google-driven" development experience as well. The copy-pasting from SO trope has existed for some time, but it's much worse in the last 5-7 years with the increase of blogspam/LLM generated content on Medium that's SEO'd to the top and effectively just rewriting the "getting started" page of some language/framework/tool/etc. for resume boosting points.

It seems like a lot of the models in ChatGPT and Copilot were trained on that content and in turn tends to produce a lot of dead end solutions for anything that isn't the 90% cases and often leads to more pain than reading documentation and building a solution through iteration/experimentation.

Maybe that's part of the reason why "strider" bikes are becoming a lot more common for toddlers to learn how to ride a bike. They're effectively what the OP describes, a bike with no pedals that you run and then balance on.

What I've found helps me with hobby jumping or not completing tasks/practicing/etc. is to not talk about it. If I'm going to do a task or work on a hobby the act of saying I'm going to do something triggers the same dopamine reward as actually doing the thing. Instead I try to only talk about things that are already done in order to hold myself a little bit more accountable for actually working on stuff.

Wasn't the original benefit of Perl that it was fairly close to a standard tool, i.e. it was available on pretty much any server you would be pushing a script to anyways?

Raku doesn't seem to have the same ubiquity, while Python is generally available on any system, or even Perl5 is still widely available on pretty much any system. I'd love to start using Raku more but it seems like a hard sell over Python or Bash