Live data from Hacker News

Configuring My Machines with Bashtard

tyil.nl

41–50 of 59 posts

Re: Configuring My Machines with Bashtard

#41
post #38

Earlier quoted context omitted.

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.

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.

Re: Configuring My Machines with Bashtard

#42
post #12
post #6

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.

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?

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.

Re: Configuring My Machines with Bashtard

#43
post #36

Earlier quoted context omitted.

> 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)…

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…

> 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.

Re: Configuring My Machines with Bashtard

#44

Earlier quoted context omitted.

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.

https://en.m.wikipedia.org/wiki/Git_(slang)

"Git" is an insult, but it's not a slur.

Re: Configuring My Machines with Bashtard

#45

Earlier quoted context omitted.

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.

https://en.m.wikipedia.org/wiki/Git_(slang)

No post body was provided.

Re: Configuring My Machines with Bashtard

#46
post #8

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.

Re: Configuring My Machines with Bashtard

#47
post #22

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…

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.

Re: Configuring My Machines with Bashtard

#48

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 re…

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.

Re: Configuring My Machines with Bashtard

#49
post #12
post #6

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.

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.

Re: Configuring My Machines with Bashtard

#50
post #36

Earlier quoted context omitted.

> 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)…

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…

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.

Post reply on HN