To be fair, I would totally be willing and probably would do this, just to try to prove that I could, even just to myself. At least until the audience got bored and walked away after the 37th “open bracket”…
Logs (and in this case, Verbose Mode) aren't for knowing what a thing is currently doing as its doing it, it's for finding out what happened when the thing didn't do what you expected or wanted.
> Is it possible to bore for my own water supply, install solar+inverter/battery backup for electricity, get a medical degree to treat my own wounds? Sure but most would say it’s not reasonable.
I’m feeling attacked. Here I was thinking my lifelong work of self sufficiency for my family was completely reasonable until you came along. Thanks a lot!
The talk was obviously extremely time-limited, as demonstrated when they basically skipped the last handful of slides and then it abruptly ended. I think for the time allocated, it was just right, and they did include a couple of examples where it made sense.
For desktop, server, web, mobile, etc. This holds true. Not so much for embedded systems, anything with unnatractive memory capacity or processor performance. Rust is starting to make it's way in, but C and even assembly is still king AFAIK.
If anyone has any guides or blogs related to migrating away from Chrome for a multi-decade user (thousands of bookmarks, saved pages/read later, etc.) I would sure be interested.
Every time I try to migrate my very large bookmark collection to another browser, it either misbehaves and partially loses some data or fails completely.
> want Docker containers running locally, know that that's what they want, and know how it all works, but then don't want to do the small handful of commands at the prompt needed to get it running
Consider the case of a team of people collaborating on a software stack - the prototypical use case includes Docker Compose at the simplest and a full K8s stack at the extreme. There is quite often a minimum of 3 containers here; frontend, API/Backend and a database server. If you start to add observability tools, async/batch/event execution, caching, automated integration testing, etc, the number of "layers" in the stack grows quickly. In addition, each component may have unique per-environment or even per-user customizations.
Often one ore two people will manage the stack itself and provide instructions on how to get the whole thing working for others using a specific defined selection of easy to use tools that essentially offer minimal prerequisite knowledge to use
"Install X, run Y, get to work."
It saves a lot of time for the intern on the UI team who just wants to add a component to one page and test it locally and not also have to learn how to deploy the entire stack from scratch.
> "...you are better off making your own models to do this"
I'm doubtful you meant what you wrote here. Using a readymade UI or API to perform an effectively magical task (for most of us) is an entirely different paradigm to "just train your own model."
In reality, for us non-ML model training mortals, we're actually probably better off hiring a human to do basic data entry.
You have heard of the Prison Indistrial Complex right? Our Prisons have been For-Profit for a long time now. Totally legal, government sanctioned privatized penitentiaries.