Re: [Radmind-users] My mind is blown

[James R. <rey...@bi...>]

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