Minkata Update Build #264 2021.01.19

[rarified]

I said no mechanical sounds on The Cart, NOT the harvester. When you get to the end and ride the cart up into the factory.

I still think that sound was present for me. I would have noticed if things went silent. I'll check again.

_R

[Hoikas]

I plead mercy as I incorporated the new release shortly after I came off narcotic pain medication from surgery when I updated Minkata.

That's understandable--I'm not sure I would be much more successful at manually updating a file server in that case. That being said, this is a gentle reminder that these kinds of problems already have an automated solution that has been well-tested for about a year now. It seems like we keep having trivially preventable issues related to files missing from the manifest. Are there any changes that could be made to better accommodate Minkata? -- For example, I have been considering removing the dependency on libHSPlasma.

[rarified]

... Are there any changes that could be made to better accommodate Minkata? -- For example, I have been considering removing the dependency on libHSPlasma.

Actually, there are, if you have the energy to invest in them.

The biggest hurdle I have to overcome even investigating your utility is that I cannot see what it will do without using it. "Just try it and it will work" doesn't fly for me. And I haven't had time to more than superficially glance at the source (which btw is very nicely done from what I read.)

I would propose two alterations. You may already have these modes of operating present in the current utility, I just don't know.

• A dry-run mode of operation.
  If you read my mbmutil utility I sent to you shortly before you released your code, you may have noticed every function has a --dry-run option. This option goes through the process of determining what needs to be done, but does not actually make any changes. Depending on the level of verbosity selected when running the utility, it would tell you both why and what it would do without doing anything. I'd like to have this capability, so that even if I don't use your utility to update the server, I could obtain a task list of what needed to be updated. Assuming of course it doesn't make assumptions about directory layout/placement that render it unable to cope with my organization.
• A generation mode that does not do anything in-place, but rather stages them.
  If an .mbm file needed to be updated, the utility would produce a .mbm.new file instead of writing to the existing file, and output a notification the file was updated. I often write small shell scripts in the form:
  • bash$ sed -e 's/foo/bar/' old.txt > new.txt && mv old.txt old.txt.old && mv new.txt old.txt && echo SUCCESS || echo FAIL
  that staggers the operations with tests at each step of the procedure. I might use the utility to generate updates, but use another method to actually put them in-place on the server.

[Hoikas]

The utility does currently have a --dry-run operation - it generates the output into a temporary directory, outputting however much log information you ask for, then deletes it when the tool is finished. I'm not sure if the log outputs exactly the information you're looking for - the default level certainly doesn't - but that could be adjusted easily. The tool was designed to be authoritative in that no manual tweaking or observation is particularly needed, and the defaults reflect that.

I think the best way to add a staging option would be to specify staging directories in the config file, so the delta would be available with the exact filenames, just in a different directory. Then, you can more trivially examine the delta between revisions or copy them over. The way the tool is written, though, it always outputs all of the manifests (mbm, mbam). Though maybe that could be changed to output just the changed manifests. If this would work, I can look into adding the feature.

The tool does assume that the files are laid out on the file server in largely the same layout as the client though. I know that's not a requirement of the protocol itself, but imposing that limitation made the code a lot easier to write .

[Treehugger]

I said no mechanical sounds on The Cart, NOT the harvester. When you get to the end and ride the cart up into the factory.

I still think that sound was present for me. I would have noticed if things went silent. I'll check again.

_R

Sorry not to have been clear, when I said I had ridden the harvester in both directions, that included the cart element too.

Edited - and just for completeness' sake, I've just ridden the cart only, in both directions, and again the sound was fine.

[Treehugger]

Minkata has been updated with the new manifest, and I have confirmed it was updated on my Minkata installation.

_R

Rarified and Doobes, I just visited the pub again, to check the updated version, and when I clicked on the book, the new version took 15 minutes to load Was the new version especially huge?

[rarified]

Rarified and Doobes, I just visited the pub again, to check the updated version, and when I clicked on the book, the new version took 15 minutes to load Was the new version especially huge?

No, it should only be a few megabytes. It may have been a network performance glitch.

_R

[hhhenry]

I put on my warm clothes and rechecked the cart and the sound is fine now.

[rarified]

[Transcribed from Discord#hood by Acorn]

Acorn Today [Saturday 2021.01.30] at 3:40 AM

The new decorations look good to my untutored eye, but I did notice, inspired by @calumTraveler 's detailed reporting, that the wings of the chairs in the conference room don't have their collisions set up correctly. My avvie could pass through the top edge of the wing.