Following leader's GUI is not a choice, I feel like you never did such endeavor as building an alternative to a well-known software in it's way to enshitification : people will ask and complain if the alternative is too far from their comfort zone.
The good part is that if you have better solution you actually can suggest a PR and/or implement it for yourself.
The bot verification is not specific to Forgejo/Codeberg a lot of Foss project and organization use this method to avoid unnecessary bot traffic. I understand the issue you have with it but the problem is way larger than codeberg here.
Also about the login with GitHub button would be immensely annoying for the community : you came from GitHub and you might think that your experience is more important but as this is community driven and not a business the people actually creating and using the software don't need nor want to prioritize such button but leave the option for those who wants it, which is very nice of them. Eventually if the majority start thinking a GitHub login is preferred an issue can be created and a change made in that direction.
I also have an older Odroid HC4, it's been years it is running smoothly and not only I cannot use 1000$ for a NAS as the current post implied but the power consumption seems crazy to me for a mere disk-over-network usage (using a 500W power supply).
I like the extensive benchmark from hardkernel, the only issue is that any ARM-based product is very tricky to boot and the only savior is armbian.
This is a very good move, using more open technology benefits everyone in the long run.
Aside from the bitter words against Github (and I read comments here forgetting about the very real consequences with people lives like collaboration with ICE), using codeberg is using Forgejo : those technology are by us and for us. Unlike Github we can run our own if necessary and all the technology (actions and such) can be improved and be shared between us.
An other benefit of Forgejo/Codeberg is the absence of pushing for paying more, Github is not free and lives of users going to Azure/Gemini or other Mircrosoft services. There are many parts that are made/changed to nudge people into paying more and more and be vendor-locked.
I like my life to have the fewest dark patterns as possible and Coderberg is extremely helpful.
Other people might have other preferences. Maybe we could have a price system where people can express their preferences by paying for things with money, providing more money to the product which is in greater demand?
Sure.. Except some people / companies have so much more money, they can demand impractical things and pay above-market rates for them, causing all others to scramble to live day-to-day with the distorted market.
I'm using my self-hosted forgejo. I don't see any benefit of git-annex over LFS so far, I'm not even sure I could setup annex as easily.
Digging a little bit I found that git-annex is coded in haskell (not a fan) and seems to be 50% slower (expected from haskell but also only 1 source so far so not really reliable).
I don't see appeal of the complexity of the commands, they probably serve a purpose. Once you opened a .gitattributes from git-LFS you pretty much know all you need and you barely need any commands anymore.
Also I like how setting up a .gitattribute makes everything transparent the same way .gitignore works. I don't see any equivalent with git-annex.
Lastly any "tutorial" or guide about git-annex that won't show me an equivalent of 'git lfs ls-files' will definitely not appeal to me. I'm a big user of 'git status' and 'git lfs ls-files' to check/re-check everything.
Annex isn't slow because it's written in Haskell, it tends to be slow because of I/O and paranoia that's warranted as the default behavior in a distributed backup tool.
E.g. if you drop something it'll by default check the remotes it has access to for that content in real time, it can be many orders of magnitude faster to use --fast etc., to (somewhat unsafely) skip all that and trust whatever metadata you have a local copy of.
LFS and git-annex have subtly different use cases in my experience. LFS is for users developing something with git that has large files in the repo like the classic game development example. git-annex is something you'd use to keep some important stuff backed up which happens to involve large files, like a home folder with music or whatever in it. In my case I do the latter.
This would require the SinglyLinkedList to be generic and would require that the data struct use "node" as the field name. Also, as some comments have pointed out, this type of linked list can be useful when a data struct needs to be in multiple lists, in which case there is no single "node" field.
const some_data = struct {
// Some data fields
// ...
bar_node: SinglyLinkedList.Node,
baz_node: SinglyLinkedList.Node,
};
I find the "why" points not appealing to me (maybe I know my way around git too much), but one:
"Partial clones
Commutation makes it possible to clone only a small subset of a repository: indeed, one can only apply the changes related to that subset. Working on a partial clone produces changes that can readily be sent to the large repository. "
It is scary that someone can say it is "encrypting" a private key by applying a simple XOR.
Also :
"File-Based Index: We track file hashes in a small JSON index instead of re-hashing everything on every commit or switch. This makes commits and merges faster because Evo only re-hashes files if it notices a changed modtime"
Using modtime is not a good idea at all, this is very telling about how much author knows about different workflow. For those who don't know : you can have remotely mounted files where your machine and the server time is different (happens to me and realized that makefile is modtime based and it creates problem), also obviously clock can change and you do not want your version control system to be blind on changed file, ever.
The good part is that if you have better solution you actually can suggest a PR and/or implement it for yourself.
The bot verification is not specific to Forgejo/Codeberg a lot of Foss project and organization use this method to avoid unnecessary bot traffic. I understand the issue you have with it but the problem is way larger than codeberg here.
Also about the login with GitHub button would be immensely annoying for the community : you came from GitHub and you might think that your experience is more important but as this is community driven and not a business the people actually creating and using the software don't need nor want to prioritize such button but leave the option for those who wants it, which is very nice of them. Eventually if the majority start thinking a GitHub login is preferred an issue can be created and a change made in that direction.
reply