tristan/journal
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Fixed spelling mistake

Browse Source
This commit is contained in:
Tristan Ancelet 2023-11-10 21:38:22 -06:00
parent 55ea05b7e9
commit 70e1e7edb0
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
Me/me.md
View File

@ -9,6 +9,6 @@ As state above, I work primarily in the engineering field. By that I mean I'm ex
Many of the servers I've had to take responsibilty of were in use MANY years before I was a teen. Many of them regulated to only using aged iptables as a firewall. Not saying anything bad about iptables, it's just not easy to standardize (and read) as firewalld. Not to mention that most of the servers I've had to admin don't even support tooling that would allow me to make it easier to automatically/automatedly admin them. Many of them only supporting python 2.4 and below (with the bare required version of python being 2.7 for ansible). Many of the servers I've had to take responsibilty of were in use MANY years before I was a teen. Many of them regulated to only using aged iptables as a firewall. Not saying anything bad about iptables, it's just not easy to standardize (and read) as firewalld. Not to mention that most of the servers I've had to admin don't even support tooling that would allow me to make it easier to automatically/automatedly admin them. Many of them only supporting python 2.4 and below (with the bare required version of python being 2.7 for ansible).
Meaning I've had to use bash to setup a automation server. Which allowed me to (at least) be able to have one codebase that would function on both modern and legacy systems. As both python and other codebases (compiled or otherwise would fail to function cohesively accross our servers). Especially since we have a hodge-podge of VM's and hardware servers, meaning that most of our legacy servers were running on machines supporting i686 or previous processors, meaning I couldn't just make a python scrit and compile/package it into a executable (using pyinstaller) to run accross our servers. Meaning I've had to use bash to setup a automation server. Which allowed me to (at least) be able to have one codebase that would function on both modern and legacy systems. As both python and other codebases (compiled or otherwise would fail to function cohesively accross our servers). Especially since we have a hodge-podge of VM's and hardware servers, meaning that most of our legacy servers were running on machines supporting i686 or previous processors, meaning I couldn't just make a python script and compile/package it into a executable (using pyinstaller) to run accross our servers.
The only thing I've been able to do is to write my scripts soley in bash, as it's the most super-setted language/shell there is. Meaning that it never depricates syntax or features from previous versions of the interpreted language. Meaning that both OLD an NEW scripts would function on the newer versions of the interpreter (not so much the other way around but still). The only thing I've been able to do is to write my scripts soley in bash, as it's the most super-setted language/shell there is. Meaning that it never depricates syntax or features from previous versions of the interpreted language. Meaning that both OLD an NEW scripts would function on the newer versions of the interpreter (not so much the other way around but still).