HIGHLIGHTS:
Major reorganizations this month online and off!
I now have three different Fediverse microblog accounts: one personal one on ‘realsocial.life’ (Hometown), one professional account on my self-hosted ‘m.filmfreedom.net’, and one project photo-sharing account on ‘px.filmfreedom.net’.
I cleaned, reorganized, and refiled in my office.
And I evaluated options for switching away from Git/Gitea for production files. I’ve decided that Git is simply too hard to use, although I will keep it for software projects. The replacement will likely be Nextcloud.
PRODUCTION:
Finished collecting elements from the Soyuz control panel into a library file of control props. Added the original controls I was creating for the PLSS prop.
Hosted Pepper & Carrot Episode 4, “Stroke of Genius”. This did not go quite as well as episode 3. Perhaps because we were listed lower, or because I didn’t market it as well. I’m not sure.
BUSINESS:
Started Ko-Fi account for Lunatics Project. Does not have any built-in Fediverse integration, but I will probably just use links.
Purchased a Canon Vixia HF R800 digital video camcorder for $50 from our church fundraiser, in excellent condition, which is a good choice for behind-the-scenes footage I want to take.
Sold one of my solar system poster sets.
CLEANUP:
Major straightening-up of the office. Cleared my workbench!
PR:
I have moved my personal Mastodon account onto a smaller Hometown server run by an online friend, whom I trust a lot more on moderation, as that’s very much inline with her professional work. I also created a “professional account” on my Misskey server, which is halfway between my personal account and my “LunaticsTV” brand account, under my own name @TerryHancock@m.filmfreedom.net as this is much easier for me to write for. I then created a Pixelfed “brand” account for Lunatics Project at @lunatics@px.filmfreedom.net, and I’m retiring the old “LunaticsTV” Misskey account. Unfortunately, there is no way to directly migrate followers to the Pixelfed account, because Misskey doesn’t have that feature.
DEVELOPMENT:
Tried to fix the problems with PyDev in Eclipse after the upgrade. Ran some unit tests on the LunaGen & website projects, but no real development work.
IT:
Evaluating managed-hosting options as a possible replacement for my Misskey server: Calckey and Hometown. Also looking into a Pixelfed server.
But in the end, I decided to setup a new account on my Misskey server as “TerryHancock”, to act as my professional account, while I position my new Hometown account on “realsocial.life” as my personal account. This is a lot more comfortable!
I then upgraded Narya.Net to YunoHost 11 and installed Pixelfed (which installed easily on this version), and created a “Lunatics” account there. Since this is a image-sharing account, it’s a lot better fit.ated alternatives to make production version control work. I tried using RabbitVCS in Nautilus with Git as a replacement for RapidSVN. It didn’t work that well.
I then tried SparkleShare, which is doable, but has some major interface issues that make it clunky.
Konstantin Dmitriev pointed out that they are using Nextcloud on Morevna Project, and so I evaluated that. I think it’s a clear winner, though it still falls short in a few areas: it doesn’t have the field-based metadata or the range of preview file types that ResourceSpace does, and its version control is much simpler than Git (it’s really more of a snapshot backup system). On the other hand, it may be a good compromise between ResourceSpace and Git, and it is much simpler to use.
RESEARCH:
Looked up more details on Prism-Pipeline. It is not a collaborative system. It’s more comparable to the KitCAT application that I was looking into creating.
However, in combination with Nextcloud, it might be usable.
Props Library for Controls & More Git Pain
I collected these controls into a file and made sure the objects are named descriptively to make appending them easier! I’m doing this to prepare for more set-dressing work I’ll need in Episode 2, as well as dressing the PLSS prop for the new shot in Episode 1 that I added.
It’s not that much, but I feel good about getting it done.
Git
However, I then failed to check it in, because Git remains very hard for me to work with. There’s some kind of conflict going on, which I’m sure I will figure out in time.
There’s more, but this is not the venue for troubleshooting. Don’t worry, I’m certain I will be able to figure out how to get this working.
But I have run into a lot of ways that I can get Git entangled with itself, and that’s with me working entirely by myself! I shudder to imagine what it’s going to be like to work with other artists having to use it — especially if I’m the one who has to provide the tech support.
This isn’t exactly a criticism of Git. It’s designed for a different use case. Much of the complexity serves features I simply can’t use, owing to the fact that most of the files I am managing can’t be automatically merged anyway. And many of the problems wouldn’t be such a big deal if I were only having to move kilobytes of data around, instead of gigabytes. (It’s no big deal to re-do a commit or re-clone a repo, if the whole thing is only a couple of megabytes!).
I spent a LOT of effort on the conversion from Subversion/Trac to Git/Gitea, so this is really going to be a big waste if I wind up having to abandon it.
I was hoping that I could tame the complexity with a GUI interface, not unlike the RapidSVN that I was using with Subversion. But the closest thing I could find to that was to use the Nautilus file-browser from Gnome with the RabbitVCS extensions:
Unfortunately, using that was exactly how I got into this latest snag.
I think the problems are that:
- Git is inherently more complex, with pull/push semantics on top
of the add/delete/update/commit semantics it shares with Subversion - The jargon is not always clear or consistent between applications (do
you “add” a file or “stage” it, for example?) - Git then uses arcane commands, which often need command line
switches to “do the right thing”, because the default behavior isn’t
what I want.
Of course, this is probably only a problem for the animation projects I’m trying to use it with. I doubt it will be as much of a problem for the software I’m working with (and even if it is, I can reasonably expect programmers to know Git).
My options would seem to be:
- Continue trying to tame Git’s complexity (not working yet)
- Fall back to using Subversion+Trac again (depressing!)
- Return to developing Southpaw TACTIC (heavy, time-consuming)
- Seek yet another DAM/VCS solution (but what?)
- Write my own replacement (yeah, that’s a terrible idea)
At this point, I don’t really like any of these choices. I will have to give this more thought.
The Mastodon Stampede
Unless you’ve been hiding under a rock, you have no doubt heard of the chaos that has gone on at Twitter since Elon Musk took charge there.
My feelings about Musk have always been complex. I never got the impression he was a nice human being, but on the other hand, I could appreciate the strides forward in technology under his leadership at SpaceX and Tesla.
I really wish he had stuck with those enterprises, because clearly, his talents, such as they are, do not tend towards running a social media company well. I keep thinking that he must surely be destroying Twitter on purpose, though I can only wildly speculate what the motives would be.
Twitter’s Loss is Mastodon’s Gain
There is a silver-lining, though: this has finally given Twitter users the push they needed to try alternatives, including the federated open-source social media, and Mastodon in particular.
So, the chaos at Twitter has been accompanied by a substantial growth in new users on Mastodon and the Fediverse. The total number of Mastodon users has gone from about 4.6 million to 6.7 million in 2022, and the activity level has climbed even faster. The number of “users active in the last month” (MAU) has gone from under 500,000 to over 2.7 million — more than a factor of five.
This has led to a lot of cultural conflicts and some dust-ups. In fact, I got a little touched by that myself, which is part of why I’m now at @TerryHancock@realsocial.life (a small instance just started by a friend of mine). Another reason, of course, is that the instance I was on, mastodon.art, just about doubled in size, to 26,000 people, which is getting too big for my taste.
On the other hand, I am finding a lot more of my friends on the Fediverse, now, which makes it a lot more viable as a primary social medium for me, and as a means of promoting “Lunatics!”
And, as of Nov 15, the rate of growth has slowed down a bit, so we’re getting a little time to adjust. Interestingly, the Fediverse has already responded by setting up more instances, so that the average number of users per instance has fallen back below 800. So it appears that the federated model is holding up.
Farewell to Twitter
Taking all of these things into consideration, I finally took the leap and deleted my remaining Twitter account (I had deleted my personal one a long time ago, but now I’ve also deleted the “LunaticsTV” account):
I do have a brand account set up at @LunaticsTV@m.filmfreedom.net, which is currently using Misskey, but has been plagued with performance problems. So I will probably be replacing it — hopefully at the same address, probably with a different type of server (the “Hometown” fork of Mastodon is appealing, but so is PixelFed, since it’s likely to be an image-heavy account).
This is a lot of change and a lot of distraction, as I try to keep up. I will keep you posted on changes that affect us.
SparkleShare & Nextcloud
After my frustrating experiences with Git, I decided to backtrack and try out some of my alternatives.
SparkleShare on Gitea
First, I tried out installing SparkleShare, which is a file-sharing system that uses Git as a backend. It was originally written to support designers working on software projects, and I believe I learned about it from the blog of the “Tube” project, originally. That was several years ago, now, and I wasn’t sure SparkleShare would still be in a usable condition.
However, it seems that it is. There is a Debian package, “sparkleshare” that needs to be installed on the client computer, which then uses any Git server as a backend.
I was able to get it to work with my Gitea installation.
This was probably an acceptable solution, although I did run into several usability problems with SparkleShare, which appear to be related to it having been written on the “Mono” platform. It may also have been related to assumptions of a Gnome-based environment on Linux (I was testing in the XFCE environment that Ubuntu Studio uses).
This resulted in some crashes or freezes of the program. Specifically:
- When attempting to open a folder-view of a shared folder.
- When using the working directory on a different physical disk than /home
Neither of these was truly a fatal problem. I found simple ways to work around both limitations. But it would add to the tech-support burden if we adopted SparkleShare for collaborative work.
On the other hand, one big advantage of SparkleShare is that it puts the data into Git (and Gitea). And thus, it is possible to use Git on the repository if so desired.
I wondered what this would do to the Git revision history. It appears that the revision note it adds simply identifies which file was edited, which is not too bad.
Nextcloud
After reading my previous post, Konstantin Dmitriev (from Morevna Project), told me about how they were using Nextcloud for production collaboration. In fact, he offered for us to use their instance, which was very generous.
Nextcloud is a more up-to-date collaborative file-sharing system than SparkleShare, which would eliminate Git entirely.
Instead, Nextcloud provides a simple file-based version-backup facility. This is not as sophisticated as a real version control system (VCS), of course. And there are some complications — by default, Nextcloud retires file versions according an automated schedule to save space (although this can be disabled).
One advantage to this approach is that I already have Nextcloud installed on my project server. I just wasn’t thinking of using it for production files. I had instead intended to use it just for business/management documents.
To use it for production would require some changes. Like Gitea and PeerTube, Nextcloud has a facility for putting data into object storage, which would be a good idea, considering the volume of data that production use would involve — particularly taking backup copies into consideration.
It seems clear that I could have this working in a day or two, though, if I want, which is appealing.
I also learned that Nextcloud works with Federation. I’m not quite sure how that would work for us, but it does seem like it would open up some collaborative possibilities.
On the other hand, with Nextcloud, we’d lose the subtlety of version-control operations that Git provides. I suspect that’s not a big penalty for animation production, but it bears mentioning.
I think the biggest thing I would miss is having the annotated revision history, with check-in notes. There are “activity” and “comments” metadata associated with files in Nextcloud, though. It might be possible to use these to keep track of the state of files — though it would require some discipline to use.
Of course, it would not be possible to edit most of our files through the web interface, so using Nextcloud for production would depend on synchronizing folders with client computers (contributors’ workstations). There is a “nextcloud-desktop” application in the Debian repository to do this on Debian-based Linux distributions, which is what I tested with. Other desktop sync packages are available for other operating systems.
I did test out the Nextcloud Desktop sync, and this is really where the program shines over SparkleShare. It was easier to configure through the GUI (no fiddling with configuration files to change where the local data would be stored). And the program was stable. I never had any crashes while using.
Probably Going to Migrate Repos to Nextcloud
Both of these are workable options. Nextcloud looks like the more painless of the two to work with, and the one that will be easiest for new contributors.
It would eliminate the need for my Gitea production repositories, which feels like some wasted effort, but I’d keep Gitea for my software projects.
I plan to implement some changes to my installation:
- Setup primary storage on Backblaze B2 / S3 storage, as I had done for Gitea and PeerTube.
- Configure it to retain all versions, to avoid accidental deletions.
- Setup folders for Library and Episode repositories.
And then I’ll give it a try.
