[Novalug] OT: old white men blabbing

Dennis Zarger denniszarger@gmail.com
Sat Aug 15 17:27:43 EDT 2020


I've got to be honest: at 28 years old, I have been using GNU/Linux as a 
daily driver for over 7 years, and have had many happy installations 
prior going back at least 16 years (cumulatively). I never bothered to 
ask my own questions (anywhere, I'm new to this LUG/ML) or interject my 
opinion because I'm an absolute lurker and still consider myself as such.

Further, just about every question I could have asked was easily 
answered with a search engine (and if they were not directly answered, 
the resources were available so I enjoyed solving the others myself).

I think the below ideas might encourage lurkers to participate more 
actively, but only to a certain degree. Though I now fit the bill of an 
"old white man" from many perspectives, I never felt unwelcome in this 
group--especially at the weekly informal meetings. The first question I 
asked was met with highly informed responses.

I wish there were some way to make people feel comfortable immediately, 
but I don't think that's really possible short of being as welcoming as 
we can. I don't feel that any member of this group has done anything 
short of that in my time participating.

I would encourage people to ask questions, and to come to the weekly 
informal meetings if they feel uncomfortable. I have full confidence 
that they will be made to feel comfortable, especially if they find some 
way to put themselves out there!

On 8/15/20 12:57 PM, Charles Richard Head via Novalug wrote:

> *NoVaLuggers,*
>
> I agree with Nino.  In an attempt to draw the discussion to some 
> action we can take to change things, if that is what we want to do, 
> I'd like to suggest the alternatives listed below.  I'm sure these 
> aren't the only alternatives.  Please suggest your own or improve on 
> mine:
>
> Options to draw less experienced or less outgoing individuals into the 
> discussion:
>
> 1.
>
>    Periodically announce on the list server that, although there may be
>    often be a discussion of detailed, highly complex subjects going on,
>    the list would be pleased to address other issues, of any level of
>    complexity, if anyone has such issues.
>
> 2.
>
>    Come right out and ask if there “is anyone out there” (monitoring
>    the NoVALug list server) who is hesitant to post an item. Ask them
>    what we could do to make it more likely for them to participate.
>
> 3.
>
>    Periodically initiate discussions of issues appropriate to people
>    with various levels of Linux background or expertise, such as:
>
>     1.
>
>        How to get a Linux distro from the internet and onto a USB thumb
>        drive, ready to try out or use to install Linux on a computer.
>        Assume you’ve never installed an Operating System.
>
>     2.
>
>        How to establish a Linux domain using Free IPA.
>
>     3.
>
>        How to share files between computers running Linux and Linux or
>        Linux and Window$. Maybe even include Apple computers?
>
>     4.
>
>        Other topics? Add your suggestion.
>
> 4.
>
>    Have a non-biased discussion of CLI vs GUI. Granted, the world is
>    yours if you can use a CLI. Those who can CLI are superstars.
>    However, some people (me included) only use CLI if there is no other
>    alternative. Despite my recalcitrance, I can still use Linux. How
>    can that be? If the only way to use Linux was via a CLI, I probably
>    wouldn’t bother. This might be especially interesting/useful for
>    people coming in from a Window$ or Apple background.
>
> It might also be appropriate to recognize that people who are into 
> computer operating systems and associated issues often are not the 
> most outgoing, self confidant people.  It is possible that we aren't 
> being unwelcoming.  Rather, it might be that we have to go above and 
> beyond to draw out people whose personalities do not make such 
> interactions comfortable.
>
> *Charlie Head*
> 703-979-9430
> _____________________________________________
> On 8/15/20 11:13 AM, Nino Pereira via Novalug wrote:
>> This discussion illustrates certain reactions to Peter's recent inquiry,
>> about where NoVaLUG and this mailing list may want to go.
>> Some perceived us to be a small club of old fat white men talking to 
>> each other,
>> unwelcoming to outsiders who, I'd like to imagine, include some 
>> young, hip,
>> well-dressed Cablinasian women.
>>
>> As an old white man myself, I feel perfectly at ease with letting the 
>> discussion
>> wash over me when I can't (or don't want to) follow it, and to hit 
>> delete.
>> That it can make others feel unwelcome is understandable, though.
>>
>> Nino
>>
>> On 8/15/20, Michael Henry via Novalug <novalug@firemountain.net> wrote:
>>> On 8/13/20 3:54 PM, Peter Larsen via Novalug wrote:
>>>> On 8/11/20 6:41 PM, Michael Henry via Novalug wrote:
>>>>>>> [...] for development, the system-supplied Vim is often
>>>>>>> lacking.
>>>>>> Feel free to offer up examples of this.
>>>>> The main example is for older Linux distributions that have
>>>>> outdated installations of Vim.
>>>> Again, from a system-admin's perspective, this is a bit
>>>> nonsense.
>>> Right; but this is "for development".  I'm just describing what
>>> I want from my development tools.  I don't think I've done a
>>> good job of separating my development discussion from server
>>> discussion.  I don't bother compiling Vim for servers, for
>>> example.
>>>
>>> I'd just let the next one go, but I feel like I'm flunking
>>> communication 101.  I'm not sure if I'm not expressing the below
>>> correctly, or I'm misinterpreting what you're saying, so I'll
>>> give it one more try (then I'll let it go :-)):
>>>
>>> I'd said:
>>>>> ?  I was talking here about having to live with the
>>>>> already-installed packages when necessary, not about installing
>>>>> ``nano`` when it wasn't already there; but I certainly agree
>>>>> that hardened servers with high risk of attack need to keep a
>>>>> low profile software-wise.
>>>> Any change to a production system, even if it's just adding an
>>>> editor, will/should raise alarm bells.
>>> Agreed.  But in the above discussion, I was trying to say:
>>>
>>> - Sometimes I need to login to a machine to do work (server or
>>>    workstation, either one);
>>>
>>> - Sometimes I don't get to control what's on the machine (no
>>>    authority to change, no room on the small device for more
>>>    software, whatever);
>>>
>>> - Therefore, I'm not talking here about installing an editor on
>>>    a production server;
>>>
>>> - In such cases, I am flexible enough to use whatever is already
>>>    installed, even if the only editor available is ``nano``.
>>>
>>> Maybe you were trying to say that I shouldn't even *run* an
>>> editor on a production server(?).  I'd say that depends.  It's
>>> certainly more ideal to avoid that most of the time, since
>>> editing tends to be an inherently human-involved task.  But
>>> sometimes you need to get in there and fix something, and you
>>> use the tools you have to get the job done.
>>>
>>>> But this simplification while true, misses a lot more that's
>>>> evenly important if not more:
>>>>
>>>> * Trust audit
>>>> * Repeatability - testability
>>>> * Being able to take a vacation now and then and NOT bring your 
>>>> laptop!
>>>>
>>>> (as the VISA commercial ends ... PRICELESS).
>>> I certainly agree with those goals.  That's part of why I'm not
>>> angling to become a sysadmin (being on the clock on a vacation
>>> isn't my idea of fun).
>>>
>>>>> As it stands now, one way or another that command is going to
>>>>> be manually triggered by a human.
>>>> Hmmmm - there's a difference between a human triggering 10
>>>> steps or just one step, that then triggers the 10.
>>> Sure.  In my example case, the human types a single command that
>>> does everything else.
>>>
>>>>> Neither way is going to be less
>>>>> work for the human at this stage of the maturity of this project
>>>>> (though someday I might be able to justify writing more
>>>>> automation code for this).
>>>> Once you see a fully functioning pipeline I think you'll
>>>> change your mind.
>>> I've seen fully functioning pipelines.  It's not that I don't
>>> like the idea, but there are practicalities that I have to deal
>>> with which make it non-trivial to get there.  Maybe someday, but
>>> today I'm content with the trade-offs I've had to make.
>>>
>>>> So use Ansible or similar tools to make a script to configure
>>>> a blank system installed to be like your workstation. I bet
>>>> most of that is placing key files in key locations. Now and
>>>> then, test it on a VM you create on your own workstation -
>>>> just to be sure it still works.
>>> Yes, I think in large part my workstation setup could be done in
>>> this way.  I'd even started writing some Ansible to get started
>>> on that.  But it's the sheer bulk of my installation
>>> instructions that makes the job seem large.  I haven't yet put
>>> in the time to come up with a nice incremental way to migrate
>>> slowly over to Ansible for this.  I'm not sure it would be all
>>> that hard, but it will take some time, and I've just spent a lot
>>> of time in this area already in recent days, so I'm not sure
>>> when I'll get back to it.  It's fun, though, so I expect to try
>>> it out later.
>>>
>>> The same applies to Fedora kickstart or Debian preseed or PXE
>>> boots or ....  Limited time budget for playing, and so much
>>> software to write :-)  I keep my eye on them from afar, but
>>> maybe I'll have to retire before I get a chance to try them all
>>> out.
>>>
>>>>> The way I look at it, I'm just borrowing some of the tooling
>>>>> used by real sysadmins to automate some of my workstation needs
>>>>> :-)
>>>> Perfect! But one thing is the tool, another thing is what you
>>>> can do with it. I too can go to a car-mechanics garage and
>>>> have access to all the professional tools he/she uses - but I
>>>> doubt anything good will come out of it.
>>> I think all kinds of good things would come from it, because
>>> you'd go in with the proper attitude.  You'd think "these are
>>> new tools, some of them may be unsafe if used improperly, maybe
>>> I'd better watch the safety video first and have the shop owner
>>> talk me through it the first time."  Or you'd say "that tool
>>> looks too complicated for now, I'll just use this wrench I
>>> already know how to use safely.  It might take me longer per
>>> screw, but I've only got these four screws to tighten today, and
>>> I don't want to be here all day."
>>>
>>>>> I don't want to bring the large default configuration
>>>>> file into Ansible's control, since I really care only about a
>>>>> few settings, and since that would tie me to a particular
>>>>> Ubuntu/Plasma version (or lock me into carrying along the right
>>>>> default file for each Ubuntu version I want to support).
>>>> Pretty sure it's not that large.
>>> It's not the size in bytes that bothers me, it's the fact that
>>> there are a *large* number of only semi-related configuration
>>> settings in that file.  If any of them change in the next
>>> release of Plasma, then my file is not suitable for that
>>> release.  I didn't want to be in the business of housing a fleet
>>> of different versions of this skeleton file in my Ansible
>>> configuration.  I'd rather let the system figure out the
>>> defaults, then just adjust the one or two settings I care about,
>>> since those have a better probability of staying the same across
>>> versions.  They might still change someday, but at least I'd
>>> have only a couple of variations to deal with.
>>>
>>> But Sean's idea of copying from the machine's ``/usr/share``
>>> tree solves my concern nicely here.
>>>
>>>>> Boy, I hope so, but for now this is the easiest idea I've had
>>>>> and for setting up my workstation, it's not so bad.
>>>> One step at a time but if you don't try it, nothing will ever
>>>> change.
>>> I generally agree that if you never try anything, nothing will
>>> change (although I actually suspect things would actually get
>>> *worse* instead of staying the same, if no effort is ever spent
>>> keeping up with changes in the world); but in my case, I've
>>> already taken quite a few steps in this direction lately. It's
>>> time for a breather.
>>>
>>>>> The second problem for these files is that they aren't simple
>>>>> one-line-per-configuration setting like "screensaver:off";
>>>>> they have multi-line contextual meaning, so you have to find
>>>>> a given "section", then look in the lines in that "section"
>>>>> for a "key" (like an .ini file, only worse), etc.
>>>> That is how ini files work. And they are plenty on Linux too
>>>> (bad Windows habits unfortunately made it our way).
>>> It's conceptually *similar* to INI files, "only worse".  I'd
>>> left out the details for brevity (can I even say that with a
>>> straight face now?).  It's not a standard INI file format.
>>> Section headers like ``[this]`` in an INI file are called
>>> ``groups`` in these files.  A regular INI file would do this::
>>>
>>>    [section]
>>>    key = value
>>>
>>> In these Plasma configuration files, there can be multiple group
>>> names like this::
>>>
>>>    [group1][group2][group3]
>>>    key = value
>>>
>>> For example, ``~/.config/powermanagementprofilesrc`` has::
>>>
>>>    [AC][DPMSControl]
>>>    idleTime=300000
>>>
>>>>> Plasma comes with tooling (``kwrite`` and ``kread``, as
>>>>> mentioned previously) to make it easy to deal with Plasma
>>>>> configuration files.
>>>> The problem is that you cannot tell if the operation is
>>>> required or not.  You'll have to first do a kread, THEN do the
>>>> kwrite if required.
>>> Yep.  I don't see a way around that for a surgical change to a
>>> file.  Something in the overall stack of code has to do that.
>>> You have to examine the file, see if the existing value is what
>>> you want, and modify it as necessary.
>>>
>>>> Ansible deals with state - so it needs to know how things are
>>>> before it decides what command(s) to execute. So it's a lot
>>>> more overhead. Since "ini" files are rather structural, I'm
>>>> not sure I see much benefit here.
>>> Generally Ansible doesn't have any inherent knowledge a priori
>>> about the state of the machine.  It has to go to the machine and
>>> look around.  Much of that logic is buried in Ansible modules
>>> (typically Python scripts that are sent to the machine to do the
>>> work).  Consider the ``copy`` module.  How can Ansible know a
>>> priori whether the destination file is present on the machine,
>>> or if it contains the right contents?  Ansible has to go to the
>>> machine and examine the file.  The ``copy`` module encapsulates
>>> all of that sniffing and modifying to allow the Ansible user to
>>> ignore that, and just say (as shown in the docs)::
>>>
>>>    - name: Copy file with owner and permissions
>>>      copy:
>>>        src: /srv/myfiles/foo.conf
>>>        dest: /etc/foo.conf
>>>        owner: foo
>>>        group: foo
>>>        mode: '0644'
>>>
>>> It's the job of an Ansible module to poke around on the machine
>>> and see if a change must be made, and report back if anything
>>> changed.  So I've made a module, ``kconfig``, that incorporates
>>> use of the ``kwrite`` and ``kread`` commands on the machine in
>>> order to accomplish the job.  Then the ansible script just has
>>> to do this::
>>>
>>>    kconfig:
>>>      file: powermanagementprofilesrc
>>>      groups:
>>>        - AC
>>>        - DPMSControl
>>>      key: idleTime
>>>      state: absent
>>>
>>> I did hunt around for some prior art for this, and came across
>>> an attempt or two in Ansible galaxy.  There were some things I
>>> didn't like about the example I found (I can't remember now
>>> exactly what), so I took the idea (and the name ``kconfig``) and
>>> coded up an implementation I liked better.  The parts I consider
>>> "heavy lifting" about this module are exactly the parts I lifted
>>> from the example (the name ``kconfig``, which I like, and the
>>> way the user interacts with this module).  The Python code
>>> itself is fairly straightforward.
>>>
>>> Michael Henry
>>>
>>>
>>> **********************************************************************
>>> The Novalug mailing list is hosted by firemountain.net.
>>>
>>> To unsubscribe or change delivery options:
>>> http://www.firemountain.net/mailman/listinfo/novalug
>>>
>> **********************************************************************
>> The Novalug mailing list is hosted by firemountain.net.
>>
>> To unsubscribe or change delivery options:
>> http://www.firemountain.net/mailman/listinfo/novalug
>
>
> **********************************************************************
> The Novalug mailing list is hosted by firemountain.net.
>
> To unsubscribe or change delivery options:
> http://www.firemountain.net/mailman/listinfo/novalug



More information about the Novalug mailing list