I have been operating a DNS-232 NAS with 32 MB RAM and ARM CPU with lighty webserver for a while. It could run MoinMoinWiki, written in Python 2, acceptably. Slowest thing I have tried to work on was a 386. But this one was slow - compiling the kernel took an eternity.
In that case, the curated list of applications in the Arch wiki could be invaluable for you:
https://wiki.archlinux.org/title/List_of_applications
Also, if you need something, I’ve found it often to be a good strategy to sit and write down what you personally need from a software - what are your requirements, and then go and search which available software matches these. The other way around, there are just too many alternatives: Any larger distro has tens of thousands of packages, and you won’t have time to try them all.
Oh, and there is also bup, which might be what you are looking for:
Two more interesting solutions:
And one more, the rsync tool allows to store hard-linked copies of directory trees.
The key question is however - what do you want?
These are not the same requirements, especially the volume of data will differ.
And also, while you might to want or need to go patch by patch through conflicting source code tree with 10,000 different lines, I guess that absolutely nobody is willing or has time to go through a tree with 10,000 conflicting photographs and match them.
So the question back is: What is your specific use case and what exactly do you want to achieve?
Essentially, I use tar for backup, NFS / Samba for local file sharing, and git for syncing. (For specific cases, software like Zim wiki that stores to a git backend).
And it is not that I have not tried alternative solutions - for example, I tried the Coda file system. But blending version-controlled syncing and file distribution leads to devilishly complex corner cases and failure modes.
Fun thing by the way, one can use Emacs without X, and then it is like screen - only with an editing window at the outermost shell.
And also, one can have the same space efficiency in text mode within X: Using the ratpoison or Stumpwm window managers.
ed (which is the more frugal, older brother of vi/vim) might indeed be a bit under-hyped. Which advantages does it have for you?
Funny thing a while ago I had a small side-project for a data collection task in my PDA - a kind of minimal database to record daily stuff. So, a PDA has limited screen space and typing speed, and I tried to make the UI with as little typing as possible. And then it dawned to me that I was essentially replicating ed’s interface!
You could give a try to running a gemini server like agate. It is text + file serving protocol similar to gopher.
https://en.m.wikipedia.org/wiki/Gemini_(protocol)
https://geminiprotocol.net/docs/faq.gmi
https://github.com/kr1sp1n/awesome-gemini
It is really good for organizing and distributing text, media and files like with gopher. And I think due to its simplicity, it is perfect for using it in a home or lab network.
For doing more complex tasks with git, you could have a look at jujutsu. It is really good and provides most of git’s power in an conceptually much simpler CLI interface.
Perhaps not exactly what you need, but I have been using “scrot” and the magnificient drawing program Krita for the same result.
It could be helpful if you explain what they do and how they relate to your computing needs. For example, I have been using Linux for over 25 years, and the only name in yor list which I have an idea about what it does is Deja Dup (personally, I use tar for backups, in a simple incremental setup).
Well, my main reason to use Zim Wiki and Gollum is that all the information stays on my computers -no sync service is needed, I sync via git + ssh to a Raspberry Pi that runs in my home. And this is a critical requirement for me since as a result of many experiences, my trust in commercial companies that collect data to respect data privacy has reached zero.
The differences between Zim and Gollum are gradual: Zim is tailored as a Desktop Wiki, so each page is already in editing mode which is slightly quicker, while Gollum is more like a classical server-based wiki, which is normally accessed over the browser (but by default, without user authentication). The difference is a bit blurry since both just modify a git repo, and Gollum can be run in localhost, so it is good for capturing changes on a laptop while on the road, and syncing them later. A further difference is that Zim is a but better for the “quick but not (yet) organized” style of work, while Gollum is better for a designed and maintained structure.
Both can capture media files and support different kinds of markup, while always storing in plain text. Gollum can also handle well things like PDFs which are displayed in the browser, and supports syntax highlighthing in many programming langages, which makes it nice for programming projects - it is perfect for writing outlines and documentation of software, and I often work by writing documentation first.
Interesting. Have you tried Stumpwm as well, and if so, how would you compare it to Herbstluftwm?
What makes LEO great for consistent larger documentation is that one can write things like footnotes or a glossary in nodes which can be linked into multiple pages - much like files with multiple hard links in a file system.
Also, it can re-read exported generated files into a structured outline, which is managed under version control.
Also, good support for literate programming, which is Don Knuth’s perhaps greatest idea.
You might have a look at LEO:
https://en.wikipedia.org/wiki/Leo_(text_editor)
I used it extensively for some time to write big documentation. It is good.
But I’d guess that for most tasks, Emacs org-mode is the most powerful option.
So, how many users of Debian would even think about creating own packages?
I already have a hunch what went wrong: they were probably trying to package software that has no standard build system. This is painful because the standard tools, like GNU autotools for C programs, or cmake, or setuptools or its newer siblings for python, make sure that the right commands are used to build a package on whatever platform, and that, importantly, its components are installed into the right places. If they don’t use these, they will have a problem to build packages for any standard distribution.
Guix has support for all the mayor build systems (otherwise, it could not support building of 50000 packages).
So, what exactly were they trying to do?
Yes, Nix solves the same problem. The main difference is that the language used for package descriptions is less attractive to some developers compared to the language which Guix uses, which is Guile Scheme. Guile is very mature, well documented and has good performance.
I think that will give Guix an advantage in the long run, since for a successful disyribution, one needs a bunch of packages and for this, volunteers need to write package definitions and maintain them. Guix makes it easier to write definitions.
Clearly the strict focus on FLOSS will prevent some packages like NVidia drivers from appearing there. But on the other hand, this gives you a system which you will be able to completely compile from source in 10 years time.
Guix is really making fantastic progress and is a good alternative in the space between stable and fully FOSS distributions, likes Debian, and distributions which are more up-to-date, like Arch.
And one interesting thing is that the number of packages is now so large that one can frequently install additional more recent packages on a Debian systems, or ones that are not packaged by Debian.
For example, I run Debian stable as base system, Guix as extra package manager (and Arch in a VM for trying out latest software for programming).
The thing is now Guix often provides more recent packages tham Debian, like many Rust command line tools, where Debian is lagging a bit. There are many interesting ones, and most are recent because Rust is progressing so fast. Using Guix, I can install them without using the language package manager, regardless whether iy is written in Rust, Go, or Python 3.13.
Or, today I read an article about improvements in spaced repetition learning algorithms. It mentioned that the FLOSS software Anki provided it, and I became curious and wanted to have a look at Anki. Well, Debian has no “anki” package - and it is written, among other languages, im Python and Rust, so good luck getting it on Debian stable. But for Guix, I only had to do “guix install anki” and had it installed.
This works a tad slower than apt-get … but it still saves time compared to installing stuff and dependencies manually.
Gemini is kinda a modernized version to the old Gopher protocol. Its purpose is to share hyper-linked text documents and files over a network - in the simplest way possible. It uses a simple markup language to create text documents with links, headings etc.
Here is a FAQ
Main differences with similar technologies are:
It is much, much easier to write hyper-linked documents than in HTML
a server is much much smaller and easier to set up than a web server serving HTML. It can easily and securely run on a small Raspberry Pi without special knowledge on server security.
in difference to gopher, it supports modern things like MIME and Unicode
There are clients for every platform including Android and iOS
also, there are Web gateways which allow to view stuff in a normal web browser
unlike Wikis, it is only concerned about distributing content, not modifying files. This means that the way to store and modify content can be matched to the use case: Write access to content can be via an NFS or Samba server, or via an SFTP client like WinSCP or Emacs.
the above means that it does not need user authentication
the protocol is text-centric and allows for distraction-free reading, which makes it ideal for self-hosted blogs or microblogs.
Practically, for example, I use it to share vacation photos with family.
Two more use cases that come first to my mind:
When I did my masters thesis, our lab with about 40 people had a HTTP page hosted on a file server that listed tools, data resources, software, and contact persons. That would be easier to do with Gemini because the markup is simpler. Also, today it would not be feasible to give every student write access to a wen server’s content because of the complexity of web servers, and the resulting security implications.
One time at work, we had a situation with a file server with many dozens of folders, and hundreds of documents. And because all the stuff had been growing kinda organically over many years, specific information was hard to find. A gemini server would have made it easy to organize and browse the content as collaboratively edited hypertext which serves as an index.