Configuring My Machines with Bashtard(tyil.nl)
tyil.nl
Configuring My Machines with Bashtard
https://www.tyil.nl/post/2022/05/07/configuring-my-machines-with-bashtard/
58 comments
Yeah, I was really hoping it was supposed to be pronounced like (and a play on) "bastard", but it seems like it's intended to be a mashing together of "bash" and "retard", which... oof. Maybe I misinterpreted the small note on the pronunciation, though. If so, I'd suggest the author further clarify.
> followed by “tard” (as in “bastard”)
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?
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?
[deleted]
This is so awful. I hope nobody ever actually uses it seriously.
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.
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.
Genuine question, why not? The Bash shell is one of those things that people love to hate on, and yet -- it's still here. What makes this approach inferior?
Sure, I should be clearer!
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.
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.
A shell and a programming language accomplish very different things - i.e. there's a reason pure Python makes for an annoying shell but is the next step up once you get even a little complicated.
Author should have stuck with ansible a bit longer.
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.
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.
I've tried Ansible multiple times. Every time it seemed to cost more effort to do something simple, and once you start mixing OSs, things get much more complicated very quickly.
> 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.
> 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.
I didn't look too closely at this but Ansible offers a number of guarantees such as idempotency, locking, etc. If this thing is just people wrapping their shell scripts in on of the functions this thing executes then it's automatically worse than just using Ansible. Because nobody is going to care to make their script...good.
>Ansible offers a number of guarantees such as idempotency,
You can wrap anything in ansible basically, including stuff that isn't idempotent.
Some of their modules are definitely conducive towards achieving it though.
You can wrap anything in ansible basically, including stuff that isn't idempotent.
Some of their modules are definitely conducive towards achieving it though.
my experience with ansible is that it offers a suggestion of idempotency, but there's always plenty of room to ignore the best practices.
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.
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.
I'm pretty sure that all of Ansible's core builtins guarantee idempotency
The core builtins help you to write idempotent playbooks, but it is far from a 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.
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.
Right but no configuration system can do this. Puppet straight up tends to lie about what it can do with operations named things like "ensure" which play with language to make it feel like there's not actually a procedural, stateful system there (at least based on the number of people who have gushed at me about puppet while not using it).
It's akin to "unsafe" in Rust and ansible does warn you it's a bad idea unless you really need it.
It's akin to "unsafe" in Rust and ansible does warn you it's a bad idea unless you really need it.
If it had a better name I might actually look into it.
[deleted]
Regarding the "I wrote it in bash so it doesn't add a dependency". I've been thinking recently that it might make a lot of sense for these kind of tools to be written in a compile-to-native language (e.g. Go or Rust), and embed a lightweight scripting engine (for example quickjs or luajit).
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...
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...
I don't think there's a much nicer language when it comes to system configuration than a shell. I'm not sure why people want to write an extensive, complex program in a full-on programming language for simple tasks for which the shell and it's utilities were literally invented. The shell does a great job for managing your system already, and so far I've never had a better experience by making using a more complex language.
The problem with Lua at least is that in order to do anything remotely useful you will have to pull in a bunch of 3rd party libs from luarocks or somewhere. There's basically nothing in the stdlib at all except primitive functions to build on. At least with bash the host system _is the stdlib_. And you can usually rely on that.
Seems like it should use m4 instead of sed/awk for the templating. And `make` for the dependencies that will arise, eg. HUP sshd after config change.
I've never used m4 directly, but it might be interesting to look at. I'll try to make some time to look around for information on this. If you have any pointers to get started, I'd be very interested.
The gnu m4 manual is the go-to documentation.
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.
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.
That name is problematic as it's too close to an abelist slur. You should change it to something like Bashfig, Bashful, etc. to be more inclusive.
As an actual living bastard, I endorse the name.
So. There.
So. There.
I'm all for funny names, but giving your project a needlessly inflammatory name, to me signals that the author doesn't have an interest in working with the greater open-source community to develop it further or adopt it.
"Git" is an insult, but it's not a slur.
Etymology is weird.
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.
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.
Don't be obtuse. As widely discussed in this thread, we aren't talking about "bastard."
some people want to talk about the latter section of the word "tard" being shorthand for "retard" presumably.
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.
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.
> signals that the author doesn't have an interest in working with the greater open-source community to develop it further or adopt 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.
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.
The thing that bothers me about the people who dig in and insist on continuing to use "master" is that... well... this is the hill they want to die on? If changing was some big expensive process, or if it was a name that held some sort of special historical significance (or whatever), I could maybe see the argument against. But it's... the original default branch name of a source control tool. Get over it and move on, maybe?
(Having said that, I still haven't gotten around to renaming all my existing repositories...)
(Having said that, I still haven't gotten around to renaming all my existing repositories...)
> If changing was some big expensive process
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.
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.
The appeal to arbitrariness goes both ways. If it's a minor choice, insisting it be changed is silly. "Get over it and move on" applies just as much to either.
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.
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.
Everyone has opinions over the colour of the bike shed.
I think GP is referring to the politically incorrect "-tard" part of the name.
Bashtard is one letter away from bastard. You're stretching if you're reading it as retard.
Based on the blurb in the article, I think (though it's not fully clear) that the author intends "bash retard".
I initially read it as a play on "bastard". But I'm not so sure it's a stretch. I know more than one person who likes to add the -tard suffix to all sorts of words, used in an offensive way, and it's quite hard to pronounce in a way that doesn't sound like that.
Oh, come on. It’s a lot, lot closer to bastard than retard or tard. At some point people have to own their own misperceptions.
FWIW my first thought was the same as GP, and then only later did I consider that maybe it's punning on bastard, but I still wasn't sure. Probably better to pick another name and not have to keep explaining it.
Why does it need explaining.
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.
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.
It needs to be explained that it's not using ableist language, meaning that every time it's shared a discussion like this one will take place, regardless of what you think about it.
> It needs to be explained that it's not using ableist language
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?
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 doesn't matter if you believe speech policing is valid or not. It does and will happen. I mean, look here: right now the top two top-level comments here are about the name, rather than talking about the project itself.
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.
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.
Why do you think they chose a controversial name? For fun?
The author can do what they want, but if they care what associations people have about the name and they didn't consider this, they now have new information.
b$st$rd maybe
Well, it seems to be about 50-50 in this thread alone whether it was "bastard" or "bash tard".
> At some point people have to own their own misperceptions.
I don't have to own shit. I didn't name it.
> At some point people have to own their own misperceptions.
I don't have to own shit. I didn't name it.
I first read it as "bash retard", but then thought a little more and hoped it was a play on "bastard". But then the author later (but not very clearly) explains the pronunciation, which makes me think it's intended to be "bash retard". Not a good look, if my interpretation is correct.
Yeah, I read that as Sean Connery saying "Bastard".
Could have called it "Baby Got Bash"