Posts
It's been a while since I did a weekly news update for All the Flavors, but I haven't blogged much lately either. These are updates that will be in the next release.
Light Mode Theme
Probably one of the oldest ToDo items on my list is finally done. In the next update, ATF will have a light mode, which can be set in user settings.
Persistent Page Counts
The pager selection for number of items on a page will now save between visits. That means if you always set the recipe list to show 50, next time you return it will already be set to 50. I also adjusted the default item counts to be more consistent, for instance Formulations on a Recipe will display 25 now instead of 5.
Tutorial Link for Features
I've added a new feature that will display a link to a tutorial for whatever feature is on the current page, if that tutorial exists. For instance, if you are on the Create a Recipe page and if there is a tutorial for it in our help pages, it'll display a link in the side menu to that tutorial
Expanded Home Page
The home page has had an overhaul, both in styling and how it loads the content. It will also have some new content, displaying recent batches and forum topics.
I also have several other features that are in the works, mostly totally new, but some are improvements over current features. The updates above should be active in the next few days.
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.
I made an HTML color picker for Unreal Engine 5. It's mostly for map creators, in games like Splitgate 2. UE5 uses an RGBA format that is the regular value divided by 255 (0 - 1). This color picker converts those values for you to use in maps. You can see it here: https://daviddyess.github.io/ue5-color-picker/
Splitgate 2 released at Summer Games Fest on June 6th!
The game is great and they fixed a lot of issues in the beta. The release features a Battle Royale mode named Split Worlds. I'm not a BR fan, but it is impressive the way it works. They also fixed the Linux issues, so it runs much smoother than it had during the beta.
Mantine has an 8.1.0 feature update that released this morning. Check out the changelog for details.
Splitgate 2 has been working hard to fix their server issues. Fortunately, the game play has been fantastic, even when there were other issues. They enabled support for Proton on Linux! It runs good, but not quite as well as Windows, yet. They've also fixed the XP issues, sometimes with a progress delay, and are working on Challenges. Some Challenges are beginning to work, but some aren't counting correctly or are possibly delayed. I've had no login errors, no crashes (even on Linux), and it's been nice to finally make XP progress (currently you get a double XP bonus).
Yesterday the Splitgate 2 Beta came roaring our of the gate and quickly hit a brick wall. The developers haven't given many details, but the symptoms seem to indicate they have some network bottlenecks and scaling issues. It started with in-game live updates being slow or non-existent, so transactions wouldn't show up under a player and player experience progression wasn't working either. It was just annoying at first, because every faction and weapon has a level, with each level working to unlock a new feature. No experience meant no unlocking.
To be fair, the Steam player count peaked around 12,000 players, which is probably double what was anticipated. I'm assuming console numbers were probably double or triple that at least. A Thursday morning launch probably seemed like a safe spot to get a soft launch and a chance to tweak things. Unfortunately, they had some issues hiding that soon appeared and were problematic throughout the rough day for developers. The player base has been drooling over the Beta launch date for a couple of months, but I didn't expect more than a couple of thousand players on Steam.
I did get to play the game. There was a point in the early afternoon where the player count dipped and I played 4 matches. Then late last night I was given a tip the servers were unofficially back online for some spot testing. I played another 5 matches before the servers were taken back down. The game is great! I love everything about it and can't wait for them to fix the issues so we can get back on. I really hope the player enthusiasm hasn't taken a hit, because this has been my favorite game since the 2nd Alpha test and I really want it to prosper.
Splitgate 2 Beta launched today (about 2 hours ago). I still haven't been able to play it yet. I downloaded it on Steam on Linux the moment it released, but sadly the game is locked to Steam Deck for Proton support. According to 1047, even Steam Deck support is experimental and they hope to fully support Linux in general sometime after the official launch (following the Beta). I rebooted into Windows, as soon as I saw it wouldn't work with Proton, and it wouldn't download the game. It stayed at 0% for an hour. I then decided to just wait and install Windows updates instead. That took about an hour (including a new AMD driver). Now it's downloading and locked on 3 minutes remaining for I guess eternity (still at 0% downloaded). Linux downloaded it in about 2 minutes...
1047 Games has released a new blog about the upcoming Splitgate 2 Beta. It features some exciting additions we didn't have in the Alpha:
The Lab
The new map and game mode creator in Splitgate 2 Beta looks very promising. It's collaborative, shareable, and looks like it packs tons of features.
Take Down
The original mode is back with new Simulation maps and the promise of bringing back some old Sim maps, including Charlie in the Beta.
Onslaught
The massive 8 vs 8 vs 8 game mode has a new name and 2 new massive maps
Mythic Skins, Battle Passes, Founder Packs, Oh My!
Splitgate 2 promises to push the cosmetics to a new level and it has a name, Mythic. It's an ultra rare tier and, unlike other games, it'll use the same in-game currency as everything else. It's also just cosmetic, no pay to win here. The new Battle Pass will be $5 and is followed up with an exclusive set of Founder packs to get more goodies.
Other than the Lab and Take Down, the biggest announcement of this blog post is that player progression will not reset after the Beta runs into full release.
Mantine has released it's latest version 8.0. It doesn't seem to be a big shift, if you've been running the later 7.x Mantine. You can view the change log here and check out the release announcement on Reddit. Mantine is what I use here and in all of my personal projects. I've been using it for a few years and it's definitely my preferred React UI library.
Splitgate 2 has been in development since September 2022 and 1047 Studios held several open and closed Alpha tests starting last year. After the February open Alpha, they announced there would be an open Beta in May, but had offered few details. They've recently announced the open Beta will begin on 22 May, will feature a battle pass, and will stay active until the game's official release.
This new game is basically a redesign of Splitgate 1, with the addition of factions, ability and weapon perks/attachments, and innovative game mechanics. It brings with it portals, as a central game mechanic, several game modes and unique weapons, and faction-specific abilities. My favorite game mode during the alpha testing was a giant map 8 vs 8 vs 8 battle mode. It features a tiered battle pass, with additions each month, over a 3 month period.
The official release is expected to be later (presumably October) 2025, at which point player progression will reset, but any cosmetics you've obtained will carry over into the official release. My assumption of an October release is based on comments from the CEO and to put the game battle pass in a date range for the 3 month window to reset in January. The game will have support for PC, Linux/Steam Deck, and all major consoles.
Splitgate 1 is an arena shooter with portals and various game modes, a lot of different weapons, and many different armor and weapon cosmetics. It was created by a couple of college students and was initially released for early access in 2019 and officially released in September 2022, when Splitgate 2 development was announced. It's often compared to a Halo with portals, which allow you to move around the map quickly by opening a portal at one point and a second portal at another point. One unique feature to Splitgate 1 is portal racing, which is a timed course moving through user created portals and collecting balls on the map.
It exploded in popularity while in beta, when it was released for consoles, and the game's servers quickly became overloaded. This wasn't expected by the developers, it frustrated many players, and it slowly declined in player base, even after the server issues were resolved. Splitgate 1 has sort of a cult following among it's remaining dedicated players, who have been extremely vocal about the direction of Splitgate 2. Initially, it was said that Splitgate 2 "wouldn't be a sequel, would have portals, and would be in the Splitgate universe". It is assumed the new game was named Splitgate 2 for name recognition, even though it has many differences from the original.
I have a page for this, which I need to update, but here are the Linux applications I've been using the most lately:
Zen Browser
Zen I mentioned last year when I started using it, but I'm still using it. It's based on Firefox and offers several additional features, my favorite being window transparency, tab options, and different window modes. I use the flatpak.
Zed
Zed is an IDE/code editor written in Rust, an alternative to VS Code, and I've mentioned it before as well. Their marketing point is that it's built to be used with AI, which works fine, but I rarely use that feature. I just like it because it's more performant for me [than VS Code] and it has a lot of built in features, like eslint and code formatting. I highly recommend Zed, if you want to try an alternative to VS Code. I use the flatpak.
Ptyxis
Ptyxis is a terminal for GNOME, but it works fine with KDE as well. It's a newer, prettier terminal, and it has built-in container support, which I'm slowly getting into. It doesn't have bookmark support, so it hasn't fully replaced konsole for me, which is still my default, but I use Ptyxis if I'm just doing general terminal stuff. I'm using the openSUSE Tumbleweed package.
gedit
This may seem weird, considering I use KDE, but I've made gedit my default text editor recently. Why would I ever do that? Well, Kate is really a great text editor, especially as the default for a desktop environment, but it's just too much. If I want to just edit a text file, I don't need an entire IDE to do that, I just need a simple text editor. gedit is the simplest text editor I can find that doesn't look like it was built in 1998. I'll still use Kate sometimes, but most of the time gedit is more than enough for me. I use the flatpak.
There are a few more applications I've added recently, but I haven't used them enough to really say I use them. I'll probably still add them to my Linux page though, just for reference. All of my flatpaks are installed with the --user flag. Ptyxis recommends their flatpak, but I just feel weird using a flatpak for terminal, and the Tumbleweed package seems to be maintained. I may swap gedit to a Tumbleweed package as well.
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
About a month ago, I mentioned I'd been building a scripting language named Languish. I've decided to rename it Yall. The main idea of Yall is to have a scripting language that is easy to use and learn, while having all of the features built in one would expect in a modern language. One thing I've been working on a lot is the error handling and exception system. In my opinion, this is one of the most important pieces of a language and most languages simply fail to implement a decent error handling system.
For instance, why is there ever an uncaught exception? Yall assumes that each code block, function, and method is able to throw or catch an exception. There's no need for a try-catch. If an exception propagates outside of the user code, then it is caught by a global catch, which can be configured with user code exception handlers or error types. In the user code, you can specify catch and throw as part of the return statement (or individually). There's no need for a try-catch.
Catch statements can also retry with another function, a new code block, or a loop back retry statement, which allows you to re-run that block of code or function with default or updated parameters or state. In addition to the traditional, immutable, error object, there is also a context object, which gives you a mutable object inside the exception system to define however you please.
The last thing, for error handling, I've been working on is a special kind of type for errors. These types define or structure the error handling and can be extended. I haven't worked out all of the details yet, but the idea is most of the error handling should be handled by the types assigned, and then you can supplement that, if needed, in the user code, but there should never be an unhandled error or uncaught exception, because they get handled by the interpreter if nowhere else.
I completely agree with Pate on this one.
I spent some time tonight working on the next version of Grazie!, which will be 0.7. Following my redefined roadmap, the major change is the update from Remix to React Router 7. That is mostly complete. I've also done some bug fixes and added some missing features: added delete functionality for Posts and Pages; fixed a bug where editing a Post didn't display the categories list; Pages now display status, if they are a draft, and an edit button; the Tumbleweed Snapshots feature has had a few display fixes and its feeds (RSS, Atom, & JSON) now also list the latest snapshot.
Some of the features I'd planned for 0.8 may come in 0.7 instead. This is mostly because 0.8 will, hopefully, use Rsbuild, and that looks like more of an undertaking than I initially expected. Rsbuild is working on a react-router-plugin, so that will be a lot of help, but it's not released yet. My intention is to fork that plugin to become a zulu-plugin, but Grazie! doesn't necessarily need to be running on Zulu for 0.8. I'd rather build up Zulu on the side and switch to it once it has matured some.
With that in mind, I'll probably do a few more fixes and update the main branch to 0.7, then build onto it a few incremental versions, on the way to 0.8. I would like to improve the Notes and there's also the Theme system updates and a Blocks system planned. The latter two will be transformational, as they add some very convenient features. I also want to add an RSS reader, image galleries, and auto-save.