Nvim. autopair.nvim let's you autoclose "begin[]" macros. Luasnip let's you create custom snippets for every macro you use. I also use Emmet LSP for inline svg.
Fortunately such "new choices" get abandoned very quickly. Making new solution instead of improving existing ones is counterproductive. Unless there is a large legacy codebase. Smart people have invented Unix principles to avoid that.
Not really. Best Foss projects do not always thrive. Git wasn't really better than mercurial. But it had happened to be published earlier, so it got wider adoption.
If you will create "next gen" desktop, you will just solve some problems of already existing ones and create your own. Maturity of software is far more important, than uniqueness. GNOME didn't evolve into its current state for no reason.
Kavita, same as Komga requires too much RAM.
Komga can track ebook reading progress, by converting them to images.
It doesn't support OPDS-PSE, which is the most common way of tracking progress.
Gollum. Hit integration is required if you value wiki content.
- No calibre database integration
- No web ui
- No desktop app Just the server, that scans the specified directory for books, displays them in the feed and saves progress.
Why do we invent new DEs instead of making proper settings app in already existing ones?
Linux Libre makes Guix unusable on most hardware. It also requires much effort to configure. Learn scheme, how to use shepherD, etc.
It's really cool, when automation tools create more problems than they actually solve.
There is really no reason to implement extensively audited runC in C, but the Dev only has the journey, no goals.
Not really. Void, alpine, gentoo are the only usable ones(besides non-systemd forks of arch and Debian). These are the only ones maintaining enough packages, providing enough documentation, not being just poorly maintained forks of X distro.
-
Systemd-init has a larger attack surface compared to runit, openrc, or sysVinit.
-
Systemd-logind relies on systemd, so we need to adapt it for non-systemD distributions to ensure compatibility with certain applications like GNOME.
-
Udev also depends on systemd.
-
SystemD is specific to Linux, which makes porting software to *BSD even more challenging. It's uncertain what the future holds, and there may be circumstances where Linux becomes unusable for you (e.g., compatibility issues with your laptop). Having a good alternative that doesn't require relearning everything is generally beneficial.
-
SystemD-based distributions often come with more than just "systemd-init." They include additional components like logind, resolved, networkd, systemd-timers, etc. However, many people still prefer using the alternatives they were accustomed to before systemd became popular, such as dhcpcd and cron. Consequently, having both sets of tools installed can increase the attack surface.