3 ms·
I'm actually going through some Ansible tutorials to help manage my dotfiles, and easier reproducibility of my linux desktop setups/installs. Already i see area
by mxuribe 5y ago
I'm actually going through some Ansible tutorials to help manage my dotfiles, and easier reproducibility of my linux desktop setups/installs. Already i see areas of overkill (mostly because my configs are pretty minimal, basic)...BUT...i continue with my approach to establish a flow based on ansible because i wish to learn ansible in general. If not for that ansible goal, then yeah, i probably would seek out another tool.
- kkfx 5y agoIf you are interested in Ops/classic operation Ansible is a very popular tool and learning it without much investments means essentially learn a bunch of other equivalent python/YAML tools from Salt to mcolletive etc so it's a good thing. If not IMVHO do not go much further then the initial curiosity, Ansible and similar tools have a common issue: they try to express in simple no-code manner complex things and the real practical result is that the simplification is more complicated than the original complexity of the task. We have seen a similar trend relatively relatively for config files: in the past any program needing a config have had it's own config DSL, parser etc. After some DSL became very similar and was generic enough to be adopted/copied from a program to another, ini format was one very common, XML another moderately popular from the mid '90s to mid '00 than JSON/YAML etc. They all fail eventually so some start using for configs the same programming language of the relative software so lisp software use lisp config (see Emacs), python software python configs, C for C apps (see Suckless tools) and after some times dedicated language emerge (see DHall for instance) but ultimately fails. Seeing the past for simple, but really simple, things a dead simple config files, k/v style, suffice, for the rest the similar programming language if usable for that purpose without issues (like the absurd of Suckless C usage that need wasting time recompiling all the time) is the better choice. That's why classic systems have only one language for anything (Smalltalk or Lisp to cite the most famous) and that's why NixOS is more and more popular even if Nix is really indigestible like Haskell... I expect in 5/8 years that now popular JSON/YAML will be called crap like happen for XML before for equal reasons and so the fate of the tools using them will be the same, annoying legacies that drag themselves for decades with nearly all crying against them but unable to jump out of their monsters due to the reached level of complication... If you have time my suggestion is investing time in Emacs, for me was and still is a life changer, not just for config but for anything on my desktop, in just few months it became my WM, MUA, feed reader, ... in a bit more I almost ingest all my files in it and still have to see show stopping limits...
- mxuribe 5y agoThansk, and agreed, i am learning ansible but won't be going too deep. If my job was in Ops/sysadmin/SRE then i would learn it more...but at that point it would be needed for resume and not just to learn as a hobby anyway. Since my job is not in any of those realsm, ansible will only be a brief, minor experiment. Also agreed that in a few years i also feel that json, yaml will be considered the new "xml", and receive dislike from many. > ...If you have time my suggestion is investing time in Emacs... Thanks for the recommendation. I have tried emacs in the past but it just felt like too much work to get productive in. I've been liking more and more the philosopy about each tool doing only one thing, but doing it well. And, to me, emacs seems so overwhelming. This is not a bad thing, just so far for the times that i tried emacs, it didn't click right for my work flow. I'm not a super fan of vi/vim or nano either, but it is mildly handy that those editors are always available on any linux machine that i jump into. As far as my need for other functions like feed reading, reading email, etc....so far, sticking to the practice of using each tool for only its main function seems to work out ok for me...though i have to consciously ensure i do not go overboard. so far, so good. Thanks again for your comments!
- kkfx 5y agoPersonally I've failed with Emacs years ago, just tried it and decide that's a heavy and horrid mess, I re-tried it few years ago when I see it in action and was at that point in time that I realize it's power. Emacs is one-tool one-job BUT the tool is just a function and functions can be combined like unix commands in pipes but in far more powerful manner and with far less overhead. Try seeing this: https://youtu.be/B6jfrrwR10k https://youtu.be/B6jfrrwR10k or this https://youtu.be/dljNabciEGg https://youtu.be/dljNabciEGg the real issue when starting without a friend of video-tutorials is that Emacs defaults are barebone and really old, the juicy things come only when you discover them. The power of Emacs is not much Emacs itself but the classic desktop paradigm: anything is integrated so anything can be combined. You type some math in a mail? Why not have it rendered by LaTeX, since your system do have LaTeX support installed and why not solve the ode you are typing since you have a CAS? Why being tied on GUIs to cut&paste as the sole IPC? That's is. Is extremely powerful but so different than actual environments that most users fail to comprehend without seeing it in action...