Speaking from experience?

Eh, I’ve made a decent living making commercials and corpo stuff. But not for lack of trying to get paid for art. For all the money I made working on ~50 short films and a handful of features, I could maybe buy dinner. Just like in the music industry, distributors pocket most of the profit.

Strangely, that is a lot of who is complaining. It was a Faustian bargin: draw furry porn and earn money but never be allowed to use your art in a professional sense ever again.

Then AI art came and replaced them, so it became loose-loose.

Yiff in hell furf-

Wait, what

If I’m brutally honest, I don’t find these use cases very compelling.

Separate fields for addresses could be easily solved without an LLM. The only reason there isn’t already a common solution is that it just isn’t that much of a problem.

Data ingestion from email will never be as efficient and accurate as simply having a customer fill out a form directly.

These things might make someone mildly more efficient at their job, but given the resources required for LLMs is it really worth it?

I suspect that this is “grumpy old man” type thinking, but my concern is the loss of fundamental skills.

As an example, like many other people I’ve spent the last few decades developing written communication skills, emailing clients regarding complex topics. Communication requires not only an understanding of the subject, but an understanding of the recipient’s circumstances, and the likelihood of the thoughts and actions that may arise as a result.

Over the last year or so I’ve noticed my assistants using LLMs to draft emails with deleterious results. This use in many cases reduces my thinking feeling experienced and trained assistant to an automaton regurgitating words from publicly available references. The usual response to this concern is that my assistants are using the tool incorrectly, which is certainly the case, but my argument is that the use of the tool precludes the expenditure of the requisite time and effort to really learn.

Perhaps this is a kind of circular argument, like why do kids need to learn handwriting when nothing needs to be handwritten.

It does seem as though we’re on a trajectory towards stupider professional services though, where my bot emails your bot who replies and after n iterations maybe they’ve figured it out.

Docker have many benefits - container meaning it can be more secure, easy to update and something that many overlook - a dockerfile with detailed intrusions on how to install that actually works if the container works - useful when wiki is not updated.

Another benefit is that the application owner can change infrastructure used without the user actually need to care. Example - Pihole v5 is backend dns + lighthttp for web + php in one single container. In version v6(beta) they have removed lighthttp and php and built in functionality into the core service. In my tests it went from 100 MB ram usage to 20 MB. They also changed the base from debian to alpine and the image size shrink a lot.

Next benefit - I am moving from x86 to arm for my home server. Docker itself will figure out what is the right architecture and pull that image.

Sure - Ansible exist as one attempt to combat the problem of installation instructions but is not as popular and thus the community is smaller. They may leave you in a bad state(it is not like containers were you can delete and start over fresh easily) Then we have VM:s - but IMO they waste to many resources.

Any examples spring to mind? I’ve built apps that are only distributed as containers (because for their specific purpose it made sense and I am also the operator of the service), but if ya don’t want to run it in a container… just follow the Dockerfile’s “instructions” to package the app yourself? I’m sure I could come up with a contrived example where that would be impractical, but in almost every case a container app is just a basic install script written for a standard distro and therefore easily translatable to something else.

FOSS developers don’t owe you a pre-packaged .deb. If you think distributing one would be useful, read up on debhelper. But as someone who’s done both, Dockerfile is certainly much easier than debhelper. So “don’t need it” is a statement that only favors native packaging from the user’s perspective, not the maintainer. Can’t really fault a FOSS developer for doing the bare minimum when packaging an app.

Does “doesn’t need it” mean “wouldn’t be improved by it”? Examples?

Absolutely. More spice

Cars and airplanes do have 3D printed parts. They’re much more common in the prototyping phase, but they are used in production and are making their way to space.

I completely agree with your general sentiment though. Any time a new piece of technology shows promise there are a ton of people who will loudly proclame that it will completely replace <old and busted technology> in <a massive amount of areas> while turning a blind eye to things like scaling and/or practical limitations.

See also: low/no code, which has roots going back to the 1980s at least.