BLOG Posts
I've gone around in circles for years trying to piece together the perfect platform with React. I was happy with Remix, but then they gradually de-bundled their stack. I tried to emulate it with Zulu, but the stack became too heavy. I may go back to that one day, but I'm thinking I may never need to.
Davaux is something new I'm working on that doesn't use React or much of anything else at all. It is ES6, so no compiling is required at all. There will be an optional TypeScript version, which would need to be compiled with tsc, but otherwise you just write the code and run the server. There is no configuration required by Davaux, if there's anything to configure it's because you added it. You write a component for a route, serve it, and Davaux takes care of all of the client side reactivity, it's just HTML and Javascript.
In my initial tests, which did include a full page layout and several different types of reactivity, the page sizes were around 34kb, including my added components' code/styling and the client side library served by Davaux - and that's the dev server, before stripping out dev tools for production. That did not include an UI framework, like Bootstrap or anything like that, that would of course add some overhead.
It all seems too simple, so I've scoured the web looking for anything remotely close. There's not anything I can find. It feels like everything overthinks it, while I just keep turning left and try to make it as simple as possible. It's time to turn web development back into checkers and leave the chess to the content creators.
I installed CachyOS yesterday and it went extremely well. Having been a longtime openSUSE Tumbleweed user, I wanted to set it up with Snapper and bootable snapshots in Grub. The first part of that is extremely easy. From the CachyOS Hello window on the desktop, just click "Apps/Tweaks" then click "Install Snapper Support". The prerequisite is you have to be using the default Btrfs file system. Clicking that single button will add Snapper support, which means if there is ever an issue with something you install or a system upgrade, there will be a Pre snapshot created to allow you to roll back to the moment before it was broken.
There is only one slight issue though, if you chose Grub as your bootloader. It doesn't install Snapper support for Grub automatically. According to the forums, this is because it is not easily determined which bootloader you are using. I wasn't aware of this earlier today, so when I was having boot issues, I was surprised to not find the Snapper entries available to boot from. Luckily, the issue mysteriously solved itself, after a couple of tries, and I was able to boot.
To enable Snapper support in Grub, you need to install the grub-btrfs-support package. I used Octopi to install it, but you can install from the terminal if you prefer. This package will configure everything else you need to be able to boot from Grub into Snapper snapshots, from which you can then run snapper rollback in a terminal to restore from that snapshot.
Just for an extra sense of security, I also installed the Cachy LTS kernel and the Arch LTS kernel using the Kernel Manager. Those will also show up in the Grub bootloader, so you, potentially, have more options than just rolling back if something goes wrong.
I decided I needed to go ahead and write about it while it's fresh in my memory. Overall, there is a slightly noticeable stability difference between playing Splitgate 2 using CachyOS versus playing using Tumbleweed. On Tumbleweed, there are seemingly random times when FPS drops suddenly and takes some time to recover, along with some short FPS dips here and there. It doesn't even happen in every match, but it's happened at least once every time I've played the game with Tumbleweed. I had none of that tonight on CachyOS, zero issues whatsoever. The FPS wasn't always constant, but it was steady enough that the overall game play felt more stable.
I'm not using any launch options with the game, so far. This is just CachyOS and Cachy Proton, that's the only difference. I'm running the Cachy kernel and Steam (Native) from the Cachy repos, but no manual optimizations. There are some other slight differences too. My fans aren't roaring quite as loud, my temps are a little lower, and CPU usage seems to be steadier, maybe even a little lower CPU usage.
I'm a little stunned. None of the micro-optimizations I've ever tried have ever made any noticeable difference for me in any game, not even with the kernel. This isn't micro-optimization, it's much more intensive, but I was expecting it to be pretty much the same as Tumbleweed. Let's be honest, I'm a lot stunned. I was not expecting to be questioning if I still want to use Tumbleweed as my daily driver on the very first night of testing Cachy, it hasn't even been a full day yet lol. I will admit my gaming performance on vanilla Arch was a little better than Tumbleweed, like a minuscule amount, so I should have expected some gain, but nothing as obvious as what I've seen tonight.
Beyond Splitgate 2, there are more tests to do. I still have other games I play and want to see how they perform. I'll also use some of the settings on the Cachy wiki and try those with Splitgate 2 as well, hence this is Part 1. There are things beyond even gaming, but so far it looks like there probably wont be any show stoppers there; I use a fairly simple and standard workflow for software development. The next month or so of testing CachyOS will be interesting. I doubt I would be willing to remove Tumbleweed, but I'm already wondering if I like Cachy better.
Tumbleweed isn't difficult to maintain from a user perspective 90% of the time, it's actually quite boring, it just works and if it doesn't you rollback. The challenge I'm facing is that 10%, like if you made Tumbleweed 10% better, would it be CachyOS? No worrying about codecs, I didn't have to install a single one. No need to add 3rd party repositories to watch videos or get proprietary packages. I can't even use Snapper as a reason, Cachy has it and it worked from pressing a button. The KDE experience is really good on Cachy. Dependency management has been great. Nothing I tried didn't work or even slowed me down at all. The installer is very solid. Up until this point, 90% has been great, like they don't make a better distro than that? Right?
Recap
I'm trying out CachyOS. I'm using the same base setup that I use on Tumbleweed: KDE, Btrfs, Snapper, Grub.
I'll just be coming back and editing this over time, so sorry if it's not entirely cohesive...
Very first impression: it doesn't come with Akonadi installed! Freaking +1 for Cachy. There's also a CachyOS Hello window that actually seems to be more than just informative, so I'm going to use it to setup Snapper and...whatever else looks good.
Snapper set up took about 15 seconds, including clicking into it from CachyOS Hello > Tweaks, reading the message, and typing "y".
Decided to see if I needed to do a system update, I mean it's Arch, ya know? Nope...already up to date. Nice.
It has KDE 6.4.3, but it definitely adheres more to the Arch philosophy for defaults, it's very slim and very default. In fact, the only thing I'd consider to be a normal user application that came preinstalled is just Firefox. Everything else is just utilities, including the HP print stuff, which was an option in the installer, so I added that.
KDE may be less than default? It doesn't include the Discover store and the Settings look either configured differently or lighter than I'm used to from Tumbleweed.
I like the CachyOS Kernel Manager. It shows all kernels available, which includes quite a list. Aside from various optimized, stable, or LTS options, you can also install the RC for the next kernel, which is 6.16 at the moment. That's pretty cool. For me, it came with the
cachyos-v3/linux-cachyos 6.15.6kernel. That v3 means it's optimized specifically for my type of CPU, if I'm not mistaken, which is also cool. If none of that matters to you, there are also options for standard kernels and even the zen kernel. A wide range of options.Gaming...one of the test requirements - Part 1. The CachyOS Hello window has a button to install Gaming Packages. When you run this, you get a lot of stuff: Heroic Launcher, goverlay, mangohud, steam, wine, winetricks, and a ton of other stuff. It's 4593 MiB of stuff (installed size), 228 packages added to your fastfetch or whatever it's called these days.
Cut it off here because I scared myself. There was a download error for a package in the Gaming Packages install option, so I was copying it to save for later, just in case. Well, I assume the installer got to the end and auto-focused, I'm not sure, but I was copying out of the clipboard and pasting into a text file and konsole intercepted my CTRL + C keypress. Everything seems to have installed and CachyOS Hello seems to think so, because it wont let me run it again. Luckily, I already set up Snapper, so if there's a problem we'll get to see how well that works on CachyOS :D
I'm beginning to remember why I started getting pleasantly bored with Tumbleweed. There's so much to set up on a fresh Linux install! Yes, I may be slightly contradicting my liking of a slim OS installation, but at least I didn't have to remove a bunch of stuff.
Steam is working, so I'm assuming I didn't accidentally cancel the Game Packages installation. Whew! I'm currently installing Splitgate 2 with the Cachy Proton selected for compatibility. I plan to also test it with plain Proton Experimental, just for a comparison, but I'm too curious not to try the Cachy version first.
Installed Overwatch 2, using Proton 8 (which is the same I use on Tumbleweed) in Steam. Pretty sure a newer Proton wont work, but I'll still try it later.
Installed Zed, Node.js, Discord using Octopi
Btrfs Assistant is the Snapper GUI that comes with Cachy - I confirmed it's creating Pre and Post snapshots each time I use pacman. Nice. Octopi is the Package Manager UI; it's simple, but useful.
Flatpaks seem to be discouraged for use in Cachy, which is messing with me a little. I had become accustomed to using more Flatpaks and keeping my system install simpler. It uses less space, so I'm sure my old SSD appreciates it.
I think that's enough for Day 1. I'm going to play a couple of games and see how it goes. Not using Flatpaks is making it not exactly mirror my Tumbleweed install, but that's not the end of the world. Smooth so far, other than my self jump scare. I don't want to install anything else until I have time to do some more testing and give myself room for a rollback if needed.
Honestly, if this was the only OS on my computer, I'd be pretty happy with the experience so far. We'll see how it goes playing some games...
I've been admiring CachyOS from afar for a while now. My thinking has been if I ever change distros, that would probably be the only one I'm interested in trying. I don't have any reason to change distros, so the only way I'm going to get to try it is to just install it on another drive...so that's what I'm doing. I read docs earlier, it looks impressive. I've decided to try to mirror my Tumbleweed setup, so I'm doing KDE with Btrfs, Snapper, and Grub. There are so many other options that Cachy offers, but just for this comparison, I decided to stay the same.
I like that it has a live disk with the installer, so I can write this while it installs :) Tumbleweed doesn't recommend installing from the live disk, but I haven't had to install that too many times anyway. Maybe the last live disk I ran was Garuda? Or maybe one of the 20.04 *buntu versions, when I was doing reviews on those. Possibly the last Debian. I haven't done many installs since moving to Tumbleweed.
Alright. So. It's done installing already. Since I'm dual booting, I'll probably try to work it into my work flow for a while and see how it goes. Not all at once, but over time, however long that may be. I'm not opposed to buying a new NVME just for Cachy, as I'm currently just installing it on an old 2.5" SSD (a really old one), but it has some work to do before I'd be willing to do that.
I'll try to do some blogs about it and I'll probably document my set up in a Page here, for reference. I'm looking to try it for at least a month or maybe longer and just see how well I like it. I'm curious about gaming performance, which is why I picked the same file system, overall system stability, and if it is as unbreakable as Tumbleweed. If it goes well enough, maybe I'll consider making it more permanent and giving it a better home in my system (along side Tumbleweed).
I've been working on several side projects on the weekends. I've released Surrealigrate and SurrealCTL as NPM packages. They are both on my github and I plan to create pages here for them. I'm also building a SurrealDB ORM/Generator named Axol ORM. It is already pretty good, but I need to build something with it to make sure it's good enough. In addition to the ORM/Generator functionality, I plan to have an optional application that can introspect a database an assist with generating pure surql queries from a UI.
I'd been using a predecessor to Axol ORM in the BeSquishy code base, but I haven't worked on that lately. Hopefully I can get to that sometime soon, but I have a project I need to complete that BeSquishy will use, so I've been working on that instead. This is Passage, which is a transaction server I've rebuilt several times, but I think I actually have the architecture I want this time. It's actually a very powerful real-time tool that can handle wide scale message data, whether it is for financial transactions, inventory management, chat rooms, server event and callback hooks, or something as simple as notifications.
The new approach is uses microservices that separate concerns and allows bottlenecks to be scaled as needed. Formerly, I had issues with scaling and cost efficiency, but this new approach seems to be the sweet spot. Better yet, the new approach allows it to support multiple clients, so I don't have to deploy multiple full scale instances, I can scale the edge nodes and those can then connect to dedicated services or to the wider available services.
Passage will not initially be open source, but could be one day. I plan to offer it as a pay for what you use service and potentially enterprise solutions. So that's what I've been working on other than All The Flavors stuff, which Passage will also be used for ATF as well.
I've been using the Zed editor for... checks previous blog ...about 3 months now. I've used it exclusively for projects, I don't even have VS Code on my taskbar anymore. The 1 feature I missed most from VS Code was the ability to drag and drop text in the editor. Fortunately, I realized just today that it was added, so I can't even complain about that. In my defense, it was a recent addition. Honestly, that was it, that was the 1 con I had.
So, what do I like about it? It is a more complete editor out of the box. VS Code has a lot of great extensions, but I like a very clean workspace. I don't set up a lot of things to be always on. Zed does a lot of things on its own, like checking imports and even sorting them in alphabetical order or removing unused ones. I don't need to dig into extensions for those things, they are just simple settings. If you want something different, there's probably an extension and you just change the setting, but out of the box prettier and eslint have just worked for me. I love the import sorting and cleaning, that is one of my pet peeves and it just fixes it for me.
It runs very smoothly. I have a kinda middle of the road PC, by today's standards. It's not weak, but it's not anything crazy. Zed doesn't seem to use as many resources as VS Code or any modern editor. I do think the way it works can cause resource usage to go up or down, depending on what you are doing. It's not like VS Code though; if I leave VS Code running all day or over multiple days, it will continuously consume resources at about the same amount. Zed has a smaller footprint and, unless I'm actively working in Zed, it maintains that smaller footprint, even with multiple windows open.
Finally, the 1 thing that peaked my interest in Zed in the first place, it uses Claude for it's edit predictions. I've used several in VS Code and it was nearly always just a starting point if it recommended something or it would replace a huge chunk of code that didn't need to be replaced, even breaking it most of the time. The Github suggestions were a bit better than others, but still not consistent. With Zed the prediction is nearly always right or at least enough to save some typing. I've been very happy with predictions in Zed, because most of the time I don't need them anyway, but sometimes it's a time saver and that's really what it should be all about.
I definitely recommend trying Zed editor, if you aren't too resist to some change. It's been really great for me and the simplicity of it all makes it a perfect editor.
Mantine has an 8.1.0 feature update that released this morning. Check out the changelog for details.
I have been waiting for the React Router plugin for Rsbuild for month or so. It's been released, but it still isn't fully functional. Digging through the code, I feel like Zulu may be my best bet, for both my personal projects and ATF. Zulu compiles in less than 0.2 seconds, both in development and production builds, with a minimal React app. The same app running React Router 7 + Vite is over 3 seconds to build and the dev environment is something like 45 seconds, due to the way Vite's dev server works.
Zulu uses Rsbuild with React Router 7 as a library and a tiny Zulu core to replace some of the framework functions. It still reuses quite a bit of React Router 7 framework. It also uses the Node.js HTTP server, which is faster than Express, and exposes everything you need to build upon, so less smoke and mirrors. Allora isn't as far along as Grazie, so I'm doing testing on Allora and if all goes well, then I'll implement Zulu in Grazie 0.8. The priority right now is just to verify Zulu's capabilites in Allora and then replace Remix in ATF with Zulu, if it's capable. All signs currently seem positive and I'm liking the outlook so far.
Zulu itself, I don't plan to do a lot with. I'd rather leave it as a simple and functional framework, which can be built upon. The extensibility for Grazie and Allora can be built on top of that. I don't regret the Grazie 0.7 changes, as they are a step in the right direction, but I'm still not happy with Vite and Remix/React Router 7 choosing that path makes me want to do something better.
There's an article on openSUSE news proposing Aeon and Kalpa for EU OS. On the one hand, I love openSUSE Tumbleweed, which Aeon and Kalpa are basically immutable versions of Tumbleweed. On the other hand, I'm not European and I don't really have any say in the subject, but I do have an opinion. SUSE has been pushing for openSUSE to de-brand from it, which Aeon pretty much already has. I'm hoping this is the point where openSUSE sees it also needs to actually de-brand. Fedora is a widely used distro, even in Europe, so I think it's non-branding with Red Hat may give it an advantage here. It's a smoke screen, because I already believe Red Hat still makes the decisions, but at least there's a smoke screen.
Even though Tumbleweed is a technically more advanced distro than Fedora, with snapper, openQA, zypper, yast, rolling updates, and less bureaucracy, Fedora is still just Fedora, and not Red Hat Fedora or openRH Fedora, while Tumbleweed is still openSUSE Tumbleweed. openSUSE needs to complete the re-branding, regardless of this issue, but I'm hoping this pushes it to actually happening. To me, Tumbleweed is the universal distro. You can do anything from one installer and you can do anything you want with it, whether it's repo packages or flatpaks, server or desktop. It's the perfect distro and the kind of distro that could live forever. The only time I've ever had to reinstall Tumbleweed was because my disk died. I can't say that for any other distro or even operating system.
Once again, this is a European choice and I think they are correct to be looking at it the way they are. They should worry about their security and access to reliable and standardized software. Any country should, much less an entire continent. The US is too backward to even think about having a US OS; we just care about paying lobbyists and some parasitic company's bottom line, because they donated to someone's campaign or are buddies with someone elected to office. I have my OS and that's all I can control. I think the EU would do well to pick Tumbleweed as their OS, whether directly or through Aeon and Kalpa.
I finally updated profoundgrace.org (PFG) to using Grazie!. The only unique feature from what comes with Grazie! is a KJV Bible and it has a custom theme. The code lives in a Github fork of Grazie and uses: the site folder to add the extra routes for the bible, including an override for the home page, the custom theme, and it's own favicon. This is the first functional example of reusing Grazie, without modifying anything in the app folder.
This is exciting, because it means I have a reusable code base I can build multiple things on top of and merge from upstream without a multitude of conflicts. The prisma schema will have to be de-conflicted, from time to time, but that isn't really that big of deal normally. I also have some features that I want to implement for PFG, but will also be useful as base or optional features in Grazie!. In the near future I plan to do a similar fork for Grazie! on this site, so I can begin doing customization here without changes Grazie! base code.
I've been hearing more and more about the Zed Editor lately. I don't really like change, but I do like to see what is new sometimes and potentially add things to my toolbox. I tried Theia IDE, but I couldn't find anything that made it better than VS Code, other than it wasn't VS Code, but kinda was. I can use Codium for that. When VS Code added the "free" Copilot support, I noticed someone mentioned they may have done that because of Zed.
Zed is an IDE written in Rust. So that kinda peaked my interest, mainly just out of curiosity of resource usage. From what I can tell, Zed uses about 1/4th of the memory that VS Code uses on my computer, with the same files open in the editor. It was around 300mb compared to 1.3gb, when I checked memory usage. What's crazy though, is I decided to see how that may escalate. I opened all of the files in a project that totaled about 15mb of TS files in VS Code and the memory usage jumped to about 3gb. Zed only went up to about 370mb. That is pretty crazy, kinda expected, but also we aren't used to that kind of efficiency anymore with all of these electron apps running every where. Zed is not an electron app and I quickly remembered the difference.
I like the themes in Zed and love that it includes the Gluvbox themes. In fact, I was reminded of my love for those and re-themed my desktop with a similar styling. I only used Zed a little, but it feels like an IDE that I want to use. It's light-weight. It isn't cluttered with a ton of features I never use. A lot of the things you'd need an extension for in VS Code is just built in. It's kinda refreshing. Give it a try if you want. I just installed the flatpak, because the one in the Tumbleweed repo is kinda old.
I've merged Grazie! 0.7 from the dev branch into the main branch. It doesn't have everything I wanted, but I plan to incrementally build it up to 0.8 with rsbuild and more features.
The main feature in 0.7 is the site folder. This allows you to create a custom theme and routes, without modifying anything in Grazie. You can add additional routes or override a default Grazie route. Instead of having multiple themes within Grazie itself, there is now a single default theme and you can override it with a theme in the site folder. I've migrated the project for ProfoundGrace (PFG) to the new Grazie and it works really well. PFG adds a bible, which isn't in Grazie, but it just adds those additional routes in its site folder. It also has a custom theme, again, just in the site folder.
This makes it much easier to extend Grazie!, without causing merge conflicts when you want to update your base version of Grazie. The plan is to expand these extensions and overrides, so you can have a completely custom version of Grazie running a site, without having to change anything in the base version of Grazie. As I move toward 0.8, I plan to add block extensions and overrides as well as others. I don't know if I want to allow complete overrides, yet, or if the route overrides are enough. You could theoretically completely customize your site, just by overriding routes and having your own components (or just replacing the ones you want to replace).
The 3 main things I want for 0.8 is to finish the blocks system, which includes being able to extend or override blocks; the ability to extend the dashboard; and, of course, rsbuild. I'm still waiting for the React Router extension to be published by rsbuild; they are working on it, but it still hasn't been published to NPM yet. If I figure out the code splitting issues with Zulu, I may just swap to it, because Zulu already uses rsbuild. Unfortunately, I don't know if I'll have time for that and I don't plan to have Zulu ready until we are approaching 1.0 for Grazie or maybe even later.
Finally, I will be splitting a repo off of the main Grazie repo to use for this site. I think it's time Grazie is it's own thing and this site will just expand in it's site folder, while I build onto default features into Grazie. Eventually, Grazie will have it's own web site, but I don't know if that will use the official Grazie repo or it's own fork.
I had to do some long overdue server maintenance today, so the site was done for a bit. I will be doing the react router 7 upgrade here soon as well, but I haven't had time to do all of the testing yet. I was hoping to have rsbuild ready as well, but I haven't worked out all of the kinks yet. I'll give a heads up next time; the maintenance today was just I had some time and it needed to be done.
I haven't used Firefox since October 2024. Not because of any terms of use or anything, just because my default profile kept resetting all of my settings and sync wasn't working. To be fair, I was using the developer edition, not basic Firefox, but it was enough to make me look for something new.
I have been really happy using Zen. It has had some bugs, especially early on, but over time it has become really solid. I'm also willing to try some of the others, but I typically don't change things often, so I've probably been using Zen long enough that I'll just going to continue using it :)
I have a lot of movies I ripped from my DVDs over the years. In the past we used VLC to stream videos to our TV, but our new TV uses DLNA. The issue is DLNA uses the metadata encoded in the file, so all of my movies were showing up as DVD_VIDEO, which is what the title tag defaulted to when I encoded them.
There is a CLI tool that can be used to work with image and video metadata, named exiftool. To get the title tag for a file, use exiftool -title filename. This is the tag DLNA is using to display the title for your videos. You can uses -title= to update the title tag. What I did was use a shortcut to automatically set the title as the filename: exiftool "-Title<FileName" *.m4v. You can also use a folder name instead of a file and update all of the files in that folder. If you want to process files in multiple folders under one path, add the -r flag to the command. One side-effect of this tool is it creates a copy, in case of a write error updating the data. You can override this by adding -overwrite_original to the command.
Example:
exiftool -r "-Title<FileName" -overwrite_original ./
I've used a Raspberry Pi (several actually) for my NAS setup for more than a decade. It's been convenient and inexpensive. Unfortunately, I had another Pi die and they aren't as cheap as they used to be. Allow me preface: I don't recommend using a Raspberry Pi for a NAS, unless it's one of the Pi 5's with an Nvme hat. I also don't recommend using a laptop for a NAS, even though my newest setup is using a laptop.
Recently my Raspberry Pi 3, which was running my NAS, died. I knew it was coming, because it had lasted longer than any of my prior ones and it was getting very sluggish. My setup has been an external USB, formatted to XFS, as my primary storage. I replace this external drive about every other year and step up storage. My first one was about 512gb and we're now up to several TB. I had just upgraded the storage at the beginning of the year, so I don't want to make it obsolete right away, but I also want to begin moving toward internal storage. I will say I've never had an external drive die while being used for the NAS, but I have of course had retired drives eventually die. The retired drives go in a cabinet to be snapshot of my NAS if I ever need it.
I was already planning to build a new NAS setup when I bought the new USB drive. I was not planning for my Raspberry Pi to die yet, normally once I recognized it was dying I'd have several months to replace it, so I needed a temporary solution. I have an old Acer Nitro laptop that had been my gaming laptop and then passed down through my kids. It's in pretty rough shape, but it's still functional as a computer and a lot faster than a Pi. It was just sitting on a shelf, so I decided I may as well put it to use while it's still alive and I didn't have a working NAS. It has a Nvme slot, in addition to a 2.5" SSD. I decided to use the laptop, while I'm acquiring the things I want for the new NAS. I installed OpenMediaVault on it, setup my shares from the external USB, and everything is back running again.
OpenMediaVault is a media server, built on top of Debian server. It's headless, which means it's only a server and you administer it through a web browser over the network. It's great, I've used it on my Pi's and just makes everything easier. Running on this old laptop it uses basically no resources and there are some network performance gains as well. That's my temporary setup, which works great, but not the final solution I wanted.
Some tips for OpenMediaVault:
If your network isn't connected automatically, which mine wasn't, you can use the terminal command
omv-firstaidto connect to your network. It's also useful for initial configuration of other things.If you are using a laptop, you can disable the lid close issues in systemd.
Edit
/etc/systemd/logind.confReplace
#HandleLidSwitch=suspendwithHandleLidSwitch=ignoreBe sure to remove the
#at the beginning
If you are using an external drive, I recommend one that has it's own power supply and to format it to XFS
If you only have a single storage drive, which is also the OMV filesystem drive, you can install a plugin that allows you to create shares on the filesystem drive
Sometime around snapshot 20250102 I started having issues with Flatpaks not using system fonts or cursors. Most notably in DBeaver and Zen Browser. If you have these issues, you can solve them as below.
Download the previous RPM from the Tumbleweed repos: https://download.opensuse.org/tumbleweed/repo/oss/x86_64/xdg-desktop-portal-1.18.4-1.1.x86_64.rpm
Open the location you downloaded the RPM in a terminal and run:
sudo zypper in --oldpackage xdg-desktop-portal-1.18.4-1.1.x86_64.rpm(optional) Lock the package version to skip the bad version:
sudo zypper al xdg-desktop-portal
Note: once a newer package is released, you can remove the package lock with sudo zypper rl xdg-desktop-portal
In the evenings I've been working on the reboot of ProfoundGrace.org (PFG), which is being built on top of Grazie!. I have the Bible feature working fairly well, with some additional features it didn't have before. PFG will have it's own theme, named Rock, based loosely on it's existing color scheme. The work has driven some fixes and improvements to Grazie! as well. I found some bugs in the pager and content lists: the pager currently overwrites query params external to the pager itself; the posts listing page doesn't display correctly for privileged users when there are no posts. There have also been a few little fixes here and there.
In Grazie!, I've been working on the Notes feature, which will later merge into PFG and kinda be specialized for that use case. Notes in Grazie! are mostly a feature for me or any user that registers here; they are private notes and lists, so you can only see the ones you create. I also plan to add website Bookmarks to Grazie!, but I don't know yet if they will be public or private (or both).
ProfoundGrace.org (PFG) hasn't had any updates in a while and it uses ArangoDB, so I'm converting it into SQLite so I can use Grazie! with it. I had been planning to use Allora (the SurrealDB variant of Grazie!) for it, but it seems like overkill and I was working on some JSON to SQL scripts earlier, which gave me the idea to use it with PFG. The tooling is intended for a project on ATF, but it actually works really well with SQLite as well. I have the SQLite tool in a repo, on github, named dbtools, if you want to take a peek, otherwise I'll talk about it later on when it's more capable.
I need to get back to the ATF work, which inspired this change, but I mostly have the Bible feature ported to Grazie. I'll work on it on the side and try to get it online in a couple of weeks. This was all necessary because I'm moving to SurrealDB and want to drop my ArangoDB sites/servers. Getting PFG converted gets me another step closer and SQLite makes a lot of sense for mostly static data. The content features don't get a lot of traffic, but the Bible does, so I don't want to take it down without replacing it.
I've been considering moving away from Github for a while and have moved in the past. For, I think, 2 or 3 years I used BitBucket and I hosted a private git server as well. A couple of projects I contributed to brought me back to Github and then All the Flavors chose Github. I think I'm going to start using other services again, even if I do still use Github for some. I'm going give codeberg.org a try. I had considered it not too long ago and I think I had decided to wait until they have more services set up. I don't plan to move any of my current projects, which I had done with BitBucket previously, and I may move those to Codeberg.
I have 3 projects that aren't in remote repositories and they'll probably be private for a while. I'll announce those at a later time. Anyway, just giving a heads up if anyone follows my Github. I'll be putting a link in the footer to my Codeberg at some point.
I've finally built up my SurrealDB tool set enough, I think, I can finally pick a launch date for BeSquishy. BeSquishy is a social network I've been building for a very long time. I had planned to launch it earlier this year, but had some delays and then I decided I no longer wanted to support ArangoDB. The problem is I want to build a SaaS behind BeSquishy, but ArangoDB no longer allows this with their open source package and they wont give me a quote for the enterprise package...so I had to swap databases. Seriously, they wouldn't reply to my email quote requests and when I tried their chat, they just said they'd email me, "the starting prices". They never did and I don't want to work with them anymore anyway.
Today I started building out the schema and using my SurrealDB tools in the software behind BeSquishy. With the progress I've made, I'm pretty sure I can launch sometime in October. I don't think I'll be releasing the code behind BeSquishy as open source anytime soon, but I will be releasing the tools I use to build it. I'll also be releasing an SDK, that allows you to build a web site inside BeSquishy, which you can use to power an external web site's data layer. I'll also have other services tied in, which will provide useful features you don't often have on a typical web site infrastructure.
I'll keep you updated a few times between now and then, but hopefully I can launch it in October...
I play Splitgate, which is an arena FPS with a really cool portal mechanic. Well they've been working on a new game for almost 2 years, I think, it's been a while. They stopped development on Splitgate to make the new game. Their website currently has a countdown timer and a July 18th date... Splitgaters are getting excited, but we don't know exactly what the countdown is to. Some think it's just a new teaser video. Others think it's a release. The intensity is building.
What is interesting, and potentially an indicator, is they refreshed their Discord server, so most of the old channels are gone, it has a new logo, and there are 3 new Server Status channels for Steam, Xbox, and PlayStation that are currently locked. The current Splitgate game is still online, so it's odd they would take down everything for the current game, unless the new one is actually coming soon.
Timer is down to 4 hours and 36 minutes, so I'll guess we'll know in the morning...