Being a System Administrator
Would anyone recommend a system administration certificate or course of study? I want to be "officially" trained as a system admin. I have been hacking away at it and like it, but I I think I am missing some fundamental understandings, like why do system admins tend to use Virtual Machines? Why do they use Docker nowadays? Why do system admins tend to use Red Hat based distros, etc. Any advice is appreciated!
Find local courses on GNU/Linux. Go to them.
Find online courses in places like edX or MIT OpenCourseWare. Attend them virtually.
Check out
https://en.wikipedia.org/wiki/League_of_Professional_System_Administrator
AGREE! i DID Finished a couple of YEARS AGO SOME on line courses using MIT OPENCOURSEWARE. Once where finish got my certificate, turn in a copy of my certificate got a better salary and position.
Thanks for the resources! Seems my local chapter is not on the internet anymore at least:
I'll try that MIT path though.
----- Original Message -----
From: name at domain
To: "trisquel-users" <name at domain>
Sent: Wednesday, May 17, 2017 2:12:09 PM
Subject: Re: [Trisquel-users] Being a System Administrator
AGREE! i DID Finished a couple of YEARS AGO SOME on line courses using MIT
OPENCOURSEWARE. Once where finish got my certificate, turn in a copy of my
certificate got a better salary and position.
That link is broken, it looks like you meant: https://en.wikipedia.org/wiki/League_of_Professional_System_Administrators
I don't have any online courses to recommend because most of the times I
find that either they end up recommending non-free software, non-free
documentation or forcing the student to run non-free software through
JavaScript. In such cases, I prefer to attend presencially instead of
online.
From the manuals and articles I have read about this so far, I assume
that they might want to use virtual machines and containers in order to
have control/reproducibility and not depend on the packages provided by
the host system distribution --- which most of the time only supports
one version per package and has no roll-back. However, this approach to
control/reproducibility has side effects, such as:
- In most cases theres is no way to reuse things from one container into
another. So if you have five containers depending on GTK+, then you'll
probably have five full copies of GTK+. This complicates even more if
we take into account that some containers might be using different
versions of GTK+, or that they expect/require that version (see the
next item). See
[[https://media.libreplanet.org/u/libreplanet/m/solving-the-deployment-crisis-with-gnu-guix-f8fd/]].
- Docker containers (or any kind of container) is "wraped tight", in
that if you try to change something inside it, everything might fall
apart to the point of being unrecoverable. Running `apt-get upgrade`
in a Docker container, even though *it is* provided inside it, might be
catastrophic. See the previous reference.
- Due to this "tight wrap", the providers of the containers often have
extra-work in case they have to fix a bug. /E.g./: Fixing Shellshock
would require all containers to be redone. See the previous reference.
- It can be argued that these containers might be system distribution
(even though they are not complete), and so, in order to be
free/libre, they need to follow the GNU FSDG. Even if not a system
distribution, they are still software. See the next reference.
- The default repository used by the Docker downloader often provides
non-free containers (replace containers with "system distribution" or
"software" depending on the previous item). See
[[https://lists.gnu.org/archive/html/libreplanet-discuss/2016-04/msg00103.html]].
- This might also apply to language-specific package downloaders
(/e.g./: downloader used by npm for NodeJS packages, downloader used
by pip for Python packages), but I don't have proof for this. I'm
just assuming because the package downloaders have a list of
repositories that might not have commitment to follow the GNU FSDG.
- From a developer perspective: Since the developer would probably have
to make virtual machines and containers regularly and have specific
dependencies to be met, then developer feels tempted to either
"reinvent the wheel" by making his own dependency, "bundle" the
dependency or "fork and make changes, without returning/contributing
back" to that dependency, or a mix of those three, because the
developer either fails/denies to participate/follow/discuss with the
dependencies' projects using their development discussing methods, or
he fails to adapt his project to the changes of the dependencies. See
the first reference and also
[[https://www.wingolog.org/archives/2015/11/09/embracing-conways-law]].
To fix or workaround all these issues, this is why GNU Guix (package
manager) and projects like Reproducible Builds exist.
--
- [[https://libreplanet.org/wiki/User:Adfeno]]
- Palestrante e consultor sobre /software/ livre (não confundir com
gratis).
- "WhatsApp"? Ele não é livre, por isso não uso. Iguais a ele prefiro
GNU Ring, ou Tox. Quer outras formas de contato? Adicione o vCard
que está no endereço acima aos teus contatos.
- Pretende me enviar arquivos .doc, .ppt, .cdr, ou .mp3? OK, eu
aceito, mas não repasso. Entrego apenas em formatos favoráveis ao
/software/ livre. Favor entrar em contato em caso de dúvida.
Interesting response Adfeno. Definitely mostly over my head as I am just a beginner at a great deal of these concepts. I would love to get up a machine to run the GUIX distro, especially as a server. I will do some research to check out how feasible that could be for me.
Thanks for taking the time and effort to collect those references and to explain your point of view.
----- Original Message -----
From: "Adonay Felipe Nogueira" <name at domain>
To: "trisquel-users" <name at domain>
Sent: Thursday, May 18, 2017 9:39:20 AM
Subject: Re: [Trisquel-users] Being a System Administrator
I don't have any online courses to recommend because most of the times I
find that either they end up recommending non-free software, non-free
documentation or forcing the student to run non-free software through
JavaScript. In such cases, I prefer to attend presencially instead of
online.
From the manuals and articles I have read about this so far, I assume
that they might want to use virtual machines and containers in order to
have control/reproducibility and not depend on the packages provided by
the host system distribution --- which most of the time only supports
one version per package and has no roll-back. However, this approach to
control/reproducibility has side effects, such as:
- In most cases theres is no way to reuse things from one container into
another. So if you have five containers depending on GTK+, then you'll
probably have five full copies of GTK+. This complicates even more if
we take into account that some containers might be using different
versions of GTK+, or that they expect/require that version (see the
next item). See
[[https://media.libreplanet.org/u/libreplanet/m/solving-the-deployment-crisis-with-gnu-guix-f8fd/]].
- Docker containers (or any kind of container) is "wraped tight", in
that if you try to change something inside it, everything might fall
apart to the point of being unrecoverable. Running `apt-get upgrade`
in a Docker container, even though *it is* provided inside it, might be
catastrophic. See the previous reference.
- Due to this "tight wrap", the providers of the containers often have
extra-work in case they have to fix a bug. /E.g./: Fixing Shellshock
would require all containers to be redone. See the previous reference.
- It can be argued that these containers might be system distribution
(even though they are not complete), and so, in order to be
free/libre, they need to follow the GNU FSDG. Even if not a system
distribution, they are still software. See the next reference.
- The default repository used by the Docker downloader often provides
non-free containers (replace containers with "system distribution" or
"software" depending on the previous item). See
[[https://lists.gnu.org/archive/html/libreplanet-discuss/2016-04/msg00103.html]].
- This might also apply to language-specific package downloaders
(/e.g./: downloader used by npm for NodeJS packages, downloader used
by pip for Python packages), but I don't have proof for this. I'm
just assuming because the package downloaders have a list of
repositories that might not have commitment to follow the GNU FSDG.
- From a developer perspective: Since the developer would probably have
to make virtual machines and containers regularly and have specific
dependencies to be met, then developer feels tempted to either
"reinvent the wheel" by making his own dependency, "bundle" the
dependency or "fork and make changes, without returning/contributing
back" to that dependency, or a mix of those three, because the
developer either fails/denies to participate/follow/discuss with the
dependencies' projects using their development discussing methods, or
he fails to adapt his project to the changes of the dependencies. See
the first reference and also
[[https://www.wingolog.org/archives/2015/11/09/embracing-conways-law]].
To fix or workaround all these issues, this is why GNU Guix (package
manager) and projects like Reproducible Builds exist.
--
- [[https://libreplanet.org/wiki/User:Adfeno]]
- Palestrante e consultor sobre /software/ livre (não confundir com
gratis).
- "WhatsApp"? Ele não é livre, por isso não uso. Iguais a ele prefiro
GNU Ring, ou Tox. Quer outras formas de contato? Adicione o vCard
que está no endereço acima aos teus contatos.
- Pretende me enviar arquivos .doc, .ppt, .cdr, ou .mp3? OK, eu
aceito, mas não repasso. Entrego apenas em formatos favoráveis ao
/software/ livre. Favor entrar em contato em caso de dúvida.
You're welcome! :)