There's a neat mental model that there are four kinds of documentation: tutorials, how-to guides, explanation, and reference.
I think that examples fit into the first or the second kind; I'm not too concerned which category they belong to, because the point is that all kinds all have their place.
Source: https://docs.divio.com/documentation-system/ - someone has already linked it in another comment, but I think it's worth replying because the comments in this thread are arguing about which kind they like the most.
> the most important thing I've learned about [bash] is: don't. Sure, it can be done, and even done well, but why? There are better languages.
This. Bash gives you all the tools to dig a hole and none to climb out. It's quick and easy to copy commands from your terminal to a file, and it beats not saving them at all.
Support for digging: once you have a shell script, adding one more line conditioned on some env var is more pragmatic than rewriting the script in another language. Apply mathematical induction to grow the script to 1000 lines. Split into multiple files when one becomes too large and repeat.
Missing support for climbing out: janky functions, no modules, user types, or tests; no debugger and no standard library. I've successfully refactored messy python code in the past, but with bash I've had no idea where to even start.
There is hope that LLMs can be used to convert shell scripts to other languages, because they can make the jump that experienced devs have learned to avoid: rewriting from scratch. What else do you do when refactoring in small steps is not feasible?
I wrote a powershell script to run an ffmpeg workflow. I'm confident that this was a better idea than either of the other two approaches that you seem to be advocating for:
(a) instead of writing a shell script to operate a shell-operated tool, write a python script with a bunch of os.system('shell out') commands.
(b) instead of just invoking ffmpeg to do the things you want done, install an ffmpeg development library, and call the functions that ffmpeg itself calls to do those things.
> There is hope that LLMs can be used to convert shell scripts to other languages, because they can make the jump that experienced devs have learned to avoid: rewriting from scratch. What else do you do when refactoring in small steps is not feasible?
There were some languages shown in HN that compile to sh/bash (like oilshell[0]). I would think that's also a viable vector of attack but not sure how viable it actually is i.e. maintainers might have moved on for various reasons.
Insane deep-dive! Framing texture sampling as "Ideally, we’d like to integrate over the projection of the screen pixel onto the texture" was enlightening for me. I particularly enjoyed the explanation of anisotropic filtering because it always seemed like magic to me, and in the context of aligning ellipses on textures it just makes sense :D
Me: I couldn't write anything longer than 20 lines in make - there's just one type (string), no debugger, no data structures, no standard library, and not even modules.
Buildroot developers: let's write a build system in make!
I found the learning curve to be much easier with buildroot and compared to yocto whose build system is python but uses mixed shell/python to describe the build.
Builroot errors seemed to happen much less, and easier to understand compared to Yocto errors. Also seemed easier to corrupt the Yocto environment to the point of having to wipe and start fresh
Buildroot kconfig and TUI menuconfig was super simple to find and add packages to the rootfs, even custom ones patched in to tree to out of tree directories that could be added in with a config option.
Yocto AFAICT does not have a package discovery via TUI. You have to guess at package names, add them to you config and wait for build error to say not found. It will at least sometimes recommend similar named packages or the actual package name that eg provides the library you wanted. Otherwise it’s a search on openembedded to find package recipes that are not in the Yocto poky reference.
Adding OOT tree code to Yocto is pretty simple, once you figure out to write shell/python recipe
The makefile/Kconfig way of buildroot seemed much more intuitive especially given the kernel, busybox and uboot all use kconfig. So if you’re used to those, buildroot just seemed a natural extension to the rootfs.
> Yocto AFAICT does not have a package discovery via TUI
Depends what you mean by package discovery, but `oe-pkgdata-util find-path` may be helpful in determining what package would produce a certain binary.
Other than searching on open embedded like you mention, I am not aware of a way to do this if you have not already added the layer containing the recipe.
I love the fact that he records voiceovers of his articles! I listen to podcasts on a regular basis, and this substitutes for podcast perfectly: it's shorter, but 10x higher quality.
I think that examples fit into the first or the second kind; I'm not too concerned which category they belong to, because the point is that all kinds all have their place.
Source: https://docs.divio.com/documentation-system/ - someone has already linked it in another comment, but I think it's worth replying because the comments in this thread are arguing about which kind they like the most.