QubesOS Alpine Linux Template
There is now an in-development Alpine Linux template for QubesOS. (see https://github.com/QubesOS/qubes-issues/issues/7323 and https://forum.qubes-os.org/t/alpine-linux-template-non-official-available-for-testing/20595)
Personal website
I've built a personal website on https://ayakael.net to consolidate my online presence and be more transparent about my current projects. This is to facilitate sharing what I do with the world, as I wager some of it could interesting to somebody. I hope to eventually make this a public-enough repository of my knowledge, but we'll see how that goes.
postmarketOS port for reMarkable 1 tablet
The reMarkable 1, despite its age, is still a very nice e-ink display with attached touch screen. Since the original OS is based on linux, a port to other linux distros is possible. For the most part, being the 1st generation, the hardware stays pretty close to vanilla. Thus, while the reMarkable kernel has a lot of patches, for the most part mainline can (at least) boot the iMX.6 platform that the tablet is based on. I am tracking here various tasks I need to do to get this project going.
Media management system redesign
My media système has been growing in a piece-meal style over the years. Different platforms manage different types of media, until I started consolidating around Jellyfin. Now, my music, movies, shows and books can all be accessed from one platforms. Unfortunately, the backend management is still decentralized: I use Jellyfin for managing visual media, Calibre-web to manage books and my own custom solution called DAM to manage my music.
The cool thing about the latter is that it uses git-annex as its backend and seperated metadata from data so that metadata can be stored on the git index and data can be stored in the git-annex store. DAM manages all of that, and can generate a music store and apply the metadata for when one would want to export to a device. A few issues propped up over the years:
- git-annex is not supported by forges (until now with forgejo-aneksajo)
- DAM is written in bash (ark)
- DAM uses git-annex to store CD images rather than tracks. Exporting thus takes a long while as dam has to convert to CD images in tracks and apply the metadata.
- When deploying the collection to Jellyfin, the space usages is doubled on the server as DAM convertes the collection to tracks.
- Metadata seperation is not consistent accross multiple media type.
The first issue has been solved with forgejo-aneksajo. While before I used gitolite as git-annex server, I stopped using it, and so my music collection has been growing neglected due to the opacity of operations. Now I can use forejo-aneksajo and actions to manage my music store. Now for the second issue: I've been learning more and more python and it is now time to rewrite DAM in python. As for the third issue, I want to experiment with a different backend design where everything is already stored as tracks, with the option of reconstructing the CD images, if need be. I also want to implement a 'thin repo' concept so that, the symbolic links of the repo can point to foregejo's bare repo rather than to .git.
The final issue is going to be more complicated. DAM stored metadata in the obscure mtag format. This format is really cool because, contrary to cue metadata, you can add any metadata. It's just a json file. Unfortunately, due to its obscurity, only foobar2000 can parse it. So we need a solution, because ideally Jellyfin would be able to parse it and make the media available. So either I implement a Jellyfin plugin (hard), or I change to a metadata format that Jellyfin understands (easy-ish). And on this, Jellyfin supports .nfo files to store metadata. It'd have to expriment with it to see its limits.
If this system can work, then Jellyfin can have Forgejo w/ git-annex as its backend, and metadata can be managed using .nfo files, and DAM can be used to export the metadata-less files to another directory if desired.