Re: [Radmind-users] My mind is blown

[Richard C. <rs...@um...>]

I have a version of radmind where I've abused it (ick), where I've fixed
some problems (primarily with very short transcripts), and added some
features (such as ignoring UID, GID, timestamps, and mode - so that I could
compare transcript files more easily.  I've also added buffering so that
small transcripts don't consume a file-descriptor.

Radmind knows nothing of SELinux, App-Armor, or extended attributes in file
systems.

I've built a huge library of "post-apply" scripts - but they're not
parameterized into the autoconf tools used to build radmind.

I've got a small library of tools to use an existing system managed by YUM
and generate a (mostly) complete transcript - although the flaws in this
are still significant.  I've done something similar for Python packages and
R modules.

The "parents" script needs to be fixed to deal with whitespace and
special characters in pathnames.  I have a partial solution to that - good
enough for myself.

radmind would be a lot more useful for me if it could incorporate some
identity management stuff - like symbolic UID/GID information.   radmind
ought to indicate the type of the checksum used IN the checksum - so that
you could produce mixed loadsets (or even mixed transcripts.)

When I'm more insane than usual, I'd like to have conditional ''k", "'p",
and "n".  This would likely violate the intent of radmind.

I don't recall if radmind is IPv6 aware.

--- Richard Conto
---------------------------------------------
Working remotely to support the AGC

Michigan Advanced Genomics Core (MAGC)
<https://brcf.medicine.umich.edu/cores/advanced-genomics/>
Biomedical Research Core Facilities
Medical School Administration Office of Research


On Mon, Feb 7, 2022 at 2:54 AM James Reynolds <rey...@bi...>
wrote:

> Ha. I just opened a source file in Xcode and the indentation looks like
> garbage. I’m feeling somewhat vindicated. And  now I just tried vi. Sure
> enough, it looks correct. Sigh…………………………………………………………..
>
>
>
> James
>
>
>
> On 2/7/22, 12:33 AM, "James Reynolds" <rey...@bi...> wrote:
>
>
>
> Ok. So I’ve had some time to think about this. And boy do I have a lot to
> say. I hope someone reads it.
>
>
>
> First, I asked about the indentation a whole 16 years ago.
>
>
>
> https://sourceforge.net/p/radmind/mailman/message/1105453/
>
>
>
> I don’t believe my question was understood. I don’t know how to describe
> my reaction to this now that I know what was wrong. Oh well.
>
>
>
> Next. For many years, every time I think of doing anything with the code,
> I kept debating what to do about the indentation, because I couldn’t read
> the code. Now that I know that it was a stupid tab setting, I can now read
> the code. It’s something of a rush and it changes everything for me.
> Because I can read it, I am now willing to modify the code.
>
>
>
> I don’t know if this issue has affected anyone else. Obviously people have
> known about the 8-space tab thing because a lot of people have contributed
> code. But some people might not have known about the issue, like me, and
> also been put off.
>
>
>
> Now that I’m willing to modify the code, I am going to take a stand. I’m
> not going to work with the code with mixed tabs and spaces. I’m going to
> convert all the files. I favor tabs that are 4 spaces wide. I’ve currently
> changed 13 of the files and I’ve got a lot left. This change is obviously
> going to touch every single file. And all forks and branches are going to
> have tons of conflicts if I do this. It creates a choke point. Maybe it’s a
> big enough choke point to warrant a whole new repository.
>
>
>
> But nobody is maintaining this code anyway. Nobody has submitted pull
> requests or anything in years. So if anyone cares, please say something.
>
>
>
> If I do make this change, that doesn’t mean I’ll start maintaining it. But
> it means I might. Now that I can read it, I don’t know how this will change
> my attitude and time commitment to the project. I’m already too busy with
> other things. And I know Richard Glaser is probably squirming wondering if
> this means I’m going to quit working on python-jamf and jctl. That’s not my
> plan. There’s a lot of open source projects that were abandoned and taken
> over by someone else. I don’t exactly want to become the new radmind person.
>
>
>
> Several years ago I said to people on this list that I would merge pull
> requests. I think I dropped the ball because I didn’t pay attention to the
> emails people sent immediately after I made the commitment. A big part of
> the reason is because the first commit I merged caused problems and I
> didn’t have an environment setup to actually test changes and I kind of
> stuck my head in a hole after that. And, of course, I couldn’t read the
> source code…
>
>
>
> But I know a lot more now than I did a few years ago. My C isn’t really
> better. But I know git and GitHub actions. I know Docker. I know Vagrant.
> All of those will help automate testing and packaging. And in fact, I have
> already been working on setting up automated testing and packaging. I
> didn’t even know why because I had no plans to change the source code. I
> just started doing it because I guess I wanted to use radmind again because
> I keep seeing variances in my machines that I can’t track and I need to add
> the ability to ignore timestamps to get to the bottom of it.
>
>
>
> So, unless anyone wants to chime in and argue this, I’m going to go ahead
> and finish converting all of the files to tabs and commit them into a new
> branch called something like “tabs”  and eventually I’ll merge that into
> master or create a new repository if people want. And if I ever release a
> new version of radmind, even if the code has barely changed, I’m going to
> call it 2.0. Why? Because it’s now under totally new management with a
> totally different focus, roadmap, and priorities and that is enough of a
> 2.0 for me. I will, of course, leave the copyrights and licenses the way
> they are.
>
>
>
> I know a few things about the old roadmap. I think there was something
> like unified transcripts, a GUI, and a Windows version. Where’s the garbage
> can? I’m never going to work on those things and I don’t think anyone else
> will. They will never happen unless someone coughs up some money to pay
> someone to code it and I don’t believe that will ever happen either. So we
> just need to plan on it never happening.
>
>
>
> I honestly don’t plan on figuring out the APFS issue. I think someone else
> has already solved it. I’m willing to test it and merge it, if it isn’t
> already merged (I have to look).
>
>
>
> Regarding Linux, to the best of my knowledge, radmind ignores SELinux
> settings. To be really useful, radmind probably needs to pay attention to
> SELinux. I don’t know much about AppArmor. Maybe it’s like SELinux. But
> more to the point, with containers taking over the server world and
> immutable operating systems like Fedora CoreOS, are we still going to need
> tripwires on Linux? I’m sure someone will need it. But again, with my C
> skills and lack of time, I don’t see how I could ever add SELinux or
> AppArmor support.
>
>
>
> What type of changes am I thinking of? I might change the macOS package
> identifier from edu.umich.radmind to org.github.radmind. Yeah that’s small.
> I might write some documentation. I might add the ability to ignore
> timestamps. I might fix build issues on the popular Linux and BSD variants
> (i.e. what I can get running in GitHub actions and Vagrant--that doesn’t
> include RHEL and Solaris, seeing that they aren’t free). I might try to
> make it easier to install using tools like brew, apt/yum, etc. That’s all I
> can see me having time for.
>
>
>
> And knowing how I do things, I’ll probably quit working on radmind as soon
> as I send this email. In 6 months to a year I might come back and pick up
> where I left off. Honestly, it might take me some time to get over the fact
> that for 16 years I couldn’t read the source code because of a text editor
> setting. The elation I felt when I figured this out has worn off and now I
> seem to be getting more and more bitter. Seriously, for 16 years I thought
> there was some ivory tower school of thought towards indentation that made
> absolutely no sense. But the only place I saw it revealed was in this
> project.
>
>
>
> You know what, I’m feeling so chaffed by this I just went and looked at
> GitHub’s source code view. It shows the source code correctly.  How does
> GitHub know that these files have 8 space tabs? Is that a normal thing for
> C source? I’ve looked at lots of C source files before, including the mach
> kernel and the Darwin source code, and I’ve never seen this. Is there some
> editor setting in the project files? Should I be blaming BBEdit? Is this
> because the original radmind developers used vi or emacs? The only place
> I’ve seen 8-space tabs is the terminal, and I’ve always thought it was
> horrible looking and was random. I’m revealing my ignorance. But whatever.
>
>
>
> …………………………………...
>
>
>
> Anyway.
>
>
>
> I haven’t worked that much with a community of developers and git. My day
> job is system administration, not coding. So I usually edit on master. I
> know that’s not the right way, and I’ve tried to improve. I’ll try to do it
> the right way with the radmind project. But I’m sure I’m going to do things
> wrong. If there are other people out there with more experience in this, I
> would love some advice.
>
>
>
> The old developers had discipline and high standards. I have neither. I
> don’t want to ruin the project with my inexperience and sloppiness. But
> like I said earlier, nobody is doing anything with the project. A bad
> maintainer is better than none. The old developers worked on it for their
> day job, and I don’t think anyone is ever going to get paid for working on
> radmind again. And I strongly suspect none of the old developers want to
> have anything to do with the project ever again and don’t care what happens
> to it. If any of you are out there reading, please correct me if I’m wrong.
> If anyone at Umich has any interest in this project at all, I’d love to
> hear that too.
>
>
>
> James
>
>
>
>
>
>
>
>
>
>
>
> On 2/6/22, 7:50 PM, "James Reynolds" <rey...@bi...> wrote:
>
> WARNING: Stop. Think. Read. This is an external email.
>
>
>
>
>
>
>
> So. I finally figured out the radmind source code. For over a decade I’ve
> looked at that source code with complete stupor. This last week I even went
> over the Indian Hill Style Guide trying to figure out how it justified the
> indentations. I also read a little bit of Linus Torvalds’ Linux style guide
> to see if maybe something in that could make sense of the radmind source
> code. And he says tabs should be 8 spaces, something I’ve never heard
> before. Ok, whatever.
>
>
>
>
>
>
>
> Well, today I’ve been working on the makefile trying to replace the old
> packagemaker with pkgbuild and I finally realized the makefile is formatted
> with tabs that are 8 spaces. Then I wondered if the source code files are
> the same. So I opened up a file, set the tabs to 8 spaces, and suddenly the
> source code makes complete sense. I have stayed away from the source code
> for over a decade because of this… The problem is, the whole thing is mixed
> spaces and tabs, so if your tabs are set to 4 spaces, then the whole thing
> looks like garbage.
>
>
>
>
>
>
>
> Sigh sigh sigh sigh sigh sigh sigh sigh sigh.
>
>
>
>
>
>
>
> James
> _______________________________________________
> Radmind-users mailing list
> Rad...@li...
> https://lists.sourceforge.net/lists/listinfo/radmind-users
>