Configuring My Machines with Bashtard
tyil.nl
tyil.nl
Could have called it "Baby Got Bash"
It sounds like it's intended to rhyme with "stirred" and not "starred." The latter, intended as a slur is unacceptable (imo), but the former?
As a person who has less hate than most people about bash; there are better options.
I understand the frustration with ansible, with DSLs in general and the slow creep they all take to becoming proper languages with loops and conditionals- only with worse semantics than real languages.
But this isn’t the way.
Shell semantics are terse and powerful, single character changes can completely alter the control flow of a sequence and can be very difficult to follow.
Managing data structures is also full of foot guns.
I don’t want to be too specific because you can “get around” a lot of issues if you know what you’re doing, the problem is that it’s very easy to introduce subtle bugs and not know about them for a long time- or that you can introduce bugs and not understand how or why.
Shell works great for piping together series of text and running commands in sequence and conditionally; but once you’re at the point where you’re parsing config files to do control flow and you’re sourcing more than a handful of files then controlling the quality of the script becomes very difficult.
Personally, I’ve written 100kLOC bash, I’m very comfortable with the semantics, but I still get tripped up sometimes because of some weird quirk that is not widely understood.
It can stream shell commands so you've got all the usual sed awk etc
And has a battle tested OS detection logic built in.
>This value is correct for Debian and derivatives, but not for my Gentoo or FreeBSD systems, so I’ve created OS-specific configuration files for these.
And can copy in different templates depending on OS.
Hell it can even detect whether its in a KVM or LXC or metal environment with right helpers and same for architecture so very useful for building a script that works in a very mixed environment
Still to each their own. I occasionally feel the need to reinvent a specific wheel too.
IMHO it's better to have no guarantee than a vague suggestion that you might tend to rely on but then be bitten because there's nothing actually enforcing the guarantee.
One simple example would just be to use the command task, which executes an arbitrary command. You, the developer, are responsible for telling Ansible how that should be made idempotent.
It's akin to "unsafe" in Rust and ansible does warn you it's a bad idea unless you really need it.
You can wrap anything in ansible basically, including stuff that isn't idempotent.
Some of their modules are definitely conducive towards achieving it though.
> It can stream shell commands so you've got all the usual sed awk etc
I can write a couple lines of yaml which includes the line of sed/awk/whatever, or just write the one line of sed/awk/whatever.
> And has a battle tested OS detection logic built in.
You can get pretty far with just checking /etc/os-release, and you'll need only a fraction of the code Ansible brings to do that. Ansible might do a _slightly_ better job, but the increased complexity is definitely not worth it.
> And can copy in different templates depending on OS.
Yes, it can do this, and I have done this. It's a lot of boilerplate YAML you'll need _every_ time you want to write any playbook. It's just not worth the ridiculous amount of hoop-jumping for something which seems to me to be a rather straightforward use case.
That way they could write everything in a much nicer language and still not require a dependency. For such simple scripts the relatively low performance of these embedded scripting engines would be a non-issue, and you could even provide domain-specific utility functions (e.g. for shelling out, sending http requests or otherwise interacting with the system) implemented in the the host language (Rust/Go) with full access to their library ecosystems...
One way to think about m4 is as form-substitution, eg. the ssh-config customization via sed.
Another is as text generator, eg. the classic sendmail config generator, where one writes m4 succinctly which in turn generates complex files.
From a 10,000 meter perspective, all the managed servers' config files are a projection from the central config repository. If that config is already an m4 file, then all that's left is finding the variant configs and handling them.
`make` is another nicety, as it handles the dependencies, eg. scp'ing the config and then HUP'ing the daemon only when that config changes.
So. There.
That's like saying "Scunthorpe" is 0 letters away from 'cunt'.
Git is derived from "Get" (as in "beget") which is another term for a bastard.
Watered down through the decades and much less sting, but the meaning is the same.
So I'll take you up on that, even though I fully disagree that this is the pun the author was making.
I'll start by saying that "to retard" has actual meaning, outside of derogatory statements, slurs or so on. In fact, that meaning predates by many hundreds of years: the description of people in such a way.
Since you could argue that this project is trying to speed up development, it could also argue that this is a commentary on "being retarded from your original objective" of running commands.
So, my first argument is that "to retard" can have meaning outside of being offensive, in fact, that was its primary use.
Now: Retard is a slur, absolutely. But, is it worse than Idiot? Moron?
At some point in time those were clinical definitions to mean the same thing as retard, they became used as slurs and fell out of favour.
Now, ironically, they are less inflammatory than the new derogatory word.
So, my second argument is that being offended by certain language is arbitrary.
---
Why am I arguing? Because you assume mal-intent where it's possible there is none. I genuinely assumed "bashtard" = "bastard", and that's "as offensive" to me as "git" (as a living and breathing british bastard), I didn't jump to the conclusion that it was attempting to denigrate low IQ people.
This type of language policing needs to be self-critical, because if you're not willing to be critical on what you're putting out into the world and onto other people: I will be, and you'll hate me for it.
This reminds me, there's a somewhat inherent affiliation in the flamewar over the branch name master/main.
The people who use "master" clearly don't think it's a bad term to use, and probably think being upset over it is silly. Those who use "main" either think it's (to some extent) racist to use the word master, or don't want to be yelled at.
Whichever word you chose ultimately signals affiliation, and the other group will feel you don't recognise their frustration. -- I think the sensible people just ignore it.
Rather.. I think if you want to have a community where people with different cultural attitudes feel welcome, I think some toe-stepping is inevitable and unavoidable.
(Having said that, I still haven't gotten around to renaming all my existing repositories...)
This is the main fear in every org I have seen the debate play out.
Going to every single script and tool that touches git, check and update it isn’t free, nor completely devoid of risk. Even when everyone is one the same page about the right thing to do, it’s tough to prioritize over other actual production issues.
That people have feelings about a topic that's disproportionate to its significance is characteristic of a flame-war. It's natural for people to hold strong opinions on all sorts of stuff like this. It's very human.
Even if it was a play on retard I think it's really none of your business what someone calls their thing.
The kneejerk response here to be "you have change its name" is so damn entitled.
Why? This doesn't logically follow to the author renaming their thing unless you think speech policing on the internet is some kind of valid passtime or has any weight on anything in the real world.
> meaning that every time it's shared a discussion like this one will take place
So it's a good PR move because the PC police can't figure out that just maybe every corner doesn't have a nazi around it and maybe it's just a play on bastard?
It's irrelevant what should or should not be, in this case. If you want to avoid people discussing potential controversy around the name you've chosen, then don't choose a name that has controversy potential (and if you do that by accident, graciously change it). I'm talking about outcomes here, not about what anyone might think should or shouldn't happen.
> At some point people have to own their own misperceptions.
I don't have to own shit. I didn't name it.