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.
Zulu is a server-side rendered framework for React. What makes Zulu different from other frameworks is it uses Rsbuild for its build tool/support libraries, Biome for linting and formatting, and the React Router 7 framework for routing, and it doesn't use Vite. Initially it will use Mantine for UI, for my own purposes, but I plan to provide templates, or at least a barebones version, people to choose their UI.
I personally feel this combination of tools provides a lot of functionality, so Zulu itself is actually very small, as it relies mostly on its core dependencies. It also provides a fairly straight forward migration from Remix 2 and React Router 7 framework. This is by design, as I use Remix for my personal and professional projects. The main difference between Zulu and React Router 7 framework is it doesn't use Vite and it uses a custom server built on node:http. I plan to experiment with other server options, but so far node:http has been more than adequate.
The real powerhouse behind Zulu is Rsbuild, which is blazing fast, and just very good all around. I really don't understand why more projects aren't using Rsbuild. In fact, Rsbuild was the initial step that got me to build Zulu in the first place. It's just not being used that much and it's almost silly how fast and flexible it is. A friend of mine, who generally uses SPAs, seemed quite impressed with the build speeds we are seeing in Zulu.
You can already fine Zulu in my public github repositories, if you want to take a peek. It's very much experimental and will probably be unstable until I can build up some decently sized test cases. I'm currently using it to replace React Router 7 framework (Vite) in the dev branch of Grazie!.
I think all of those names are taken, in one form or another. I'm mostly kidding anyway. But in all seriousness, I have a beginning of what could be the new base for Grazie! and potentially ATF. It works like Remix, but it doesn't use Remix, it uses React Router 7, but doesn't need Vite, it's server-side rendered, and it builds with Rsbuild. It also uses Mantine for the UI and, so far, just works. It has a few rough patches. It currently only has the production server and it's using node:http. I plan to work on the dev server next, preferably using the dev server that comes with Rsbuild.
It hasn't been easy to figure out all of the pieces. It seems not a lot of people are trying something like this. I'm not entirely against sticking with node:http for the server. I'd prefer express or maybe fastify, but it's not a deal breaker yet. I definitely want to use Rsbuild. I'd probably be happiest if someone could make a remix/react router plugin for Rsbuild, but from what I can tell all attempts at that have failed. I have been learning a lot about how Remix works internally, so maybe I could do it eventually, but I'm kinda liking the path I'm on at the moment.
The purpose of Grazie! is to have a CMS that can be used on multiple web sites, without having to start from scratch each time. It's still moving in that direction, it's not perfect for that yet, but that's where I want to get. The goal is to have Grazie that provides a reusable, stable base, and then you can extend that or override it.
Remix has been ok for the CMS piece. Unfortunately, everything I've tried with the Vite Dev server in the later versions of Remix 2 or React Router 7 has been atrocious. It's unusable as a dev server, as far as this code base goes. The production server is fine in React Router 7, but I've put too much time trying to figure out the dev server and I'm not doing it anymore. I'd rather do something else that may or may not work, either one still feels more productive.
So here's the new and amended plan:
I want to use rsbuild as my build tool.
I want to use Express server for production and rsbuild for my dev server.
I'm willing to use React Router 7 as the router, but it's losing it's luster for me.
I'll consider using Tanstack router, if it checks all of the boxes.
That's it for now. I think that's doable and then I can carry on with the more important stuff from there.
Since updating earlier, the site has had some performance issues due to Remix 2.15 and npm sucking. We had updated ESLint and npm installed the newer Remix 2 with Vite, which I do not have configured and never planned to install. I, unfortunately, had to revert that ESLint update and we are now back on the better Remix 2 version without Vite. I'm seriously reconsidering even using React Router 7 with Vite.
I've updated this site to the "latest" version of Grazie. It's now caught up with the main branch, which I'm calling 0.6. The actual latest is 0.7, which is the React Router 7 migration, but it's not ready yet. That branch isn't in the repo yet. I'll probably tag 0.6.0, as it is the last Remix 2 build, and 0.8.0, as it will be the first beta. 0.7 will be the beginning of a new dev branch in the repo.
I can't remember if I'd mentioned it before, but I've built a parser and page to track Tumbleweed snapshots. It'll be in the next site update, which should be sometime this week, I think. There will also be feeds for other sites to use. The Tumbleweed page will display what snapshot you are on, if you are using Tumbleweed, and there's a diff viewer to show package changes between the current snapshot and the past snapshots.
I haven't updated the Grazie versions in a while, so when I merge the React Router changes, I'll call it 0.7.x. Version 0.8 will have the new theme system updates, which will be a pretty big shift, and then 0.9.x will be betas and RCs.
I am not at all happy with the way the react-router dev server works, which is just vite dev. It is very slow and is basically only useful for error messages. I've put in a stop gap with nodemon and the production build/serve, which is much better, but not entirely useful as a dev server. I'm still trying to get it figured out. Unfortunately, it's the reason I hadn't migrated much sooner, even to newer Remix versions, because the dev server is just terrible.
I still have a few updates to do in the react router migration, mostly dealing with how route components changed from Remix 2, and tweaking the routing in general. It runs really well on the production server, I just want to get those few things cleaned up.
I'm not sure how much time I'll have to work on it this week, but I'd like to get this site updated with the last Remix 2 version of Grazie. I'm trying to decide if I want to launch ProfoundGrace.org with the Remix 2 version or wait and merge the React Router version into it first. It may be easiest to wait for the changes planned for 0.8.0.
Speaking of 0.8.0, my plan for it is to add a site folder outside of app, but I'm still trying to decide on the exact structure. The idea is to have the core Grazie app and then site specific stuff in the site folder, like theme, routes, and components. This makes it easier to build different sites which Grazie and makes merging upstream changes easier. I'm also thinking about dropping PostgreSQL support. Allora will have a better database alternative to SQLite, so I don't really see the point in having PG in Grazie!. It's not changing for now, but is a possibility.
I had planned to stay on Remix 2, without Vite, for a little longer, but some initial tests went well. I've rebuilt Grazie! to run on React Router 7 Framework, which is the equivalent of what would have been Remix 3. This means we get React 19 support and Vite. The latter, I'm not super impressed with. I kinda hate the Vite Dev server. It's super slow, compared to the Remix Dev server. I've tried a few things to speed it up, but I can't believe it wants to download every package file as a chunk on every refresh. That just doesn't make sense, plus it's non-responsive for a good 10 seconds after a restart. It has to be, something, not entirely correct, but I haven't figured out what, if that is the case.
The good news is the production server runs fine, so I've decided to press on. The big changes planned for February are, obviously, the RR 7/Vite migration, and then I plan to restructure the way themes and overrides work. Currently, you can override a page/layout, based on the loader value for that page, in your theme. I plan to add route and component overrides as well, but I haven't decided if those should be in the theme yet.
The goal is to build something that can be deployed and built onto for different purposes, without causing a lot of issues merging upstream changes. Th current structure is almost there, but I feel like it needs another layer between Grazie! and site specific changes. It needs a better core and customization separation, basically. That's what I hope to solve in February.
In addition to the package/framework migration, I'm also adding password resets and email support. The email support is kinda needed for the password reset. This change is driven by me moving away from bcrypt to the Node.js crypto module for password hashing. If a current user has a bcrypt hashed password, it will trigger a password reset workflow, when they try to log in.
If I get everything done, that I want to, in February, then we may be close to a beta for March. There are a few additional things I want to fix or add, but it wouldn't hurt for them to come later.
Today I merged the new RSS, Atom, and JSON feeds into Grazie!. The feeds are currently only for latest posts (up to 25 items), I plan to add feeds for categories in the future. I've decided to take a step back from the work I had done for theme component overrides. I think the block system is more important and may make component overrides unnecessary. I also worked on a page that processed Tumbleweed snapshots. That's mostly a personal thing for me, but it could be useful as an RSS feed, which I plan to add as well.