Perhaps the change that I'm most excited about is official support for using sdboot instead of grub (something I have been manually configuring for the last 7 years):
I had just spent the past 2 years mastering lilo and thought on top of the world, and then suddenly this new fangled thing called grub came along with all its weird commands and sytanx.
It's been what, 20 years now? I finally feel comfortable with grub. And now you're telling me there's a new kid on the block? sdboot?
I'm too old to learn another bootloader. Maybe I should go back and dig and old copy of Debian Potato or Woody and stick to that...
I have been using Fedora Sericea since it came out (it's basically Fedora Silverblue, but uses Sway-wm instead of Gnome-wm). The system is actually pretty usable, and you don't really need to reboot after each rpm-ostree install command (`rpm-ostree live-apply` takes care of it via systemd-based overlay).
in the last two weeks I've been using Fedora Workstation, I haven't use Linux in 20 years and i have to say this is an incredibly improved experience.
I haven't yet needed to boot back into windows! If it stays like that for the next 6 months I'll cut over to Linux permanently and wipe the windows partition.
Lutris has installers for those too, and Flatpak makes Lutris' installation a breeze.
Those are propietary, but you have Krita, Only Office, Inkscape, LibreOffice, Blender...
- Graphs of benchmark results would be neat to have. Remember to put the code and graphs as a sort of TL;DR in that blog post.
- I skimmed the code; there's no clear instructions as to how I'd use it for my own projects. Perhaps work on a CMake / Autoconf config for a library build?
- The repository itself might not have enough visibility due to being self hosted. While I do love self-hosting, maybe posting a read-only mirror on GitHub would bring in more exposure?
> Graphs of benchmark results would be neat to have. Remember to put the code and graphs as a sort of TL;DR
Thanks for the suggestion. I’ll use it when I get around to updating this page. For now though I’ll let it sit there, as I’m too tired with it at this point.
> there's no clear instructions as to how I'd use it for my own projects. Perhaps work on a CMake / Autoconf config for a library build?
It’s not meant to be used as a library. It’s only for demonstrative purposes. There are a couple choices made in this code motivated by that, like not checking for integer overflow, or hardcoding page size based on the target platform at compile time. If someone wants to use the code anyway, they should just copy it into their project and possibly modify the parts which aren’t up to snuff. That’s also what I’m doing, as I wrote a more robust version in Rust for my project. I only wrote C++ for the article, because that’s what more people are familiar with, and there are more implementations, so I got to benchmark this code against several implementations of std::vector.
As for CMake/Autotools, I think the scripts in the repo are better for my little demo, as they don’t add any dependencies beyond what’s already available on each platform, they’re more transparent and easier to use. For a big project I’d probably use CMake, but I don’t think it’s warranted here.
> The repository itself might not have enough visibility due to being self hosted. While I do love self-hosting, maybe posting a read-only mirror on GitHub would bring in more exposure?
The intended path of discovery, when it comes to the repo, is through my article. It’s not meant to be independent, so I don’t really care about the discoverability of the repo as a stand-alone thing. As for GitHub, I don’t like it for a variety of reasons and if I can help it, I’ll avoid it.
Back in the day, the demo-scene was rife with Easter eggs, often with a personal touch.
It always puts a smile on my face when I come across clever ones like this, even though that's becoming rarer these days. I guess that's due to concerns about 'hidden code' in commercial codebases, which third-party license holders might be skeptical about.
