matrss

> a pioneering (but no longer new) PR system

Having used Forgejo with AGit now, IMO the PR experience on GitHub is not great when trying to contribute to a new project. It's just unnecessarily convoluted.

How do you buy an e.V.?

I've lost my laptops SSD (as in: no longer mountable, only got data out of it with some rescue tools) at some point between 2017 and 2020, don't remember when exactly. I've also had a weird experience where a btrfs filesystem formatted on my desktop PC was not mountable on a Raspberry Pi, and vice versa formatted on the Pi was not mountable on the desktop. That didn't instill confidence either.

On the other hand, I've been running a btrfs RAID1 on two HGST datacenter drives for a few years and haven't had issues with that.

A good package manager, e.g. GNU Guix, let's you define a reproducible environment of all of your dependencies. This accounts for all of those external headers and shared libraries, which will be made available in an isolated build environment that only contains them and nothing else.

Eliminating nondeterminism from your builds might require some thinking, there are a number of places this can creep in (timestamps, random numbers, nondeterministic execution, ...). A good package manager can at least give you tooling to validate that you have eliminated nondeterminism (e.g. `guix build --check ...`).

Once you control the entire environment and your build is reproducible in principal, you might still encounter some fun issues, like "time traps". Guix has a great blog post about some of these issues and how they mitigate them: https://guix.gnu.org/en/blog/2024/adventures-on-the-quest-fo...

As well as the toolchain used to compile your toolchain, through multiple levels, and all compiler flags along the path, and so on, down to some "seed" from which everything is build.

Guix' full-source bootstrap is pretty enlightening on that topic: https://guix.gnu.org/manual/devel/en/html_node/Full_002dSour...

I responded to that comment, but it does not address why you think Forgejo is lacking development power. IMO it rather shows a lack of understanding on your part of what Forgejo is today. It no longer is a superset of Gitea since the hard fork, but its own independent project instead. And as such it has at least comparable activity to Gitea, which is reflected e.g. in the unique features that Forgejo has, but Gitea doesn't.

Re: delayed security fixes, if a vulnerability is not yet publicly known and there is no indication that it is actively abused it is common practice to schedule fixes and give advance notice of them to have administrators be prepared to update promptly. The fact that the vulnerability was leaked beforehand is unfortunate, but Forgejo handled it well with rescheduling their release in response.

Re: license change, hard forking, and new features: my understanding is that Gitea wasn't very open to contributions coming from Forgejo. The hard fork seems to be a consequence of that. Yes, there used to be weekly cherry picks, I assume they stopped exactly because Forgejo and Gitea diverged to much and they became too much of a maintenance burden. Yes, this means Gitea has gotten features that aren't present in Forgejo since then. But you miss the point of the hard fork if you count this as a negative: Forgejo is deliberately diverging from Gitea now. Cooperation didn't work out, so they are no longer a superset of Gitea, but an entirely separate project. And as such they don't have more maintenance burden than Gitea itself.

And Forgejo definitely does not lack development power as its own now-independent project. They have features themselves that Gitea doesn't have. One notable that comes to mind is storage quotas, but there are many more too.

> The ideologically forked Forgejo made some license changes and hard fork decisions that increased the maintenance burden even more, resulting in missing upstream features and decreased security. Forgejo is more busy managing ideals, than creating software.

And from other comments:

> When deciding which software fork to pick, it is about the development power.

> In my view they don't have the development to keep up with Gitea.

How do you come to the conclusion that Gitea has more development power? Looking at the Insights / Activities overview of each repository there were slightly more authors with more contributions to Forgejo over the last month. Acknowledging that this fluctuates I'd estimate that both projects are similarly active.

Also, Forgejo is actually dogfooding its development, which is much more reassuring than what Gitea does IMO.

Arguably the OG workflow to submit your code is `git send-email`, and that also doesn't require an additional third clone on the same hosting platform as the target repository.

All those workflows are just as valid as the others, I was just pointing out that the way github does it is not the only way it can be done.

To my knowledge git-lfs is only really designed to store your large files on a central server. I think it also uses its own out-of-band (from the perspective of git) protocol and connection to talk to that server. So it doesn't work with a standard ssh remote, and breaks git's distributed nature.

For an actually distributed large file tracking system on top of git you could take a look at git-annex. It works with standard ssh remotes as long as git-annex is installed on the remote too (it provides its own git-annex-shell instead of git-shell), and has a bunch of additional awesome features.

Requiring a fork to open pull requests as an outsider to a project is in itself a idiosyncrasy of GitHub that could be done without. Gitea and Forgejo for example support AGit: https://forgejo.org/docs/latest/user/agit-support/.

Nevertheless, to avoid ambiguity I usually name my personal forks on GitHub gh-<username>.

IMO "Advent of Code" only determines the timeframe in which it happens, not the amount of puzzles it must contain. It could just as well be four puzzles, one for each sunday of the advent, or any other amount, as long as they are released within those roughly four weeks before christmas.

My Sony a7iii can definitely upload to FTP by itself, JPEG and RAW. That is my primary means of getting images off of it. I would have appreciated if it did WebDAV though, then I could make it push to Nextcloud directly...

/s, right? Since the path of earth's orbit around the sun lies on a plane your decision to make the normal vector point in the same general direction of "north" seems arbitrary too. You could just as well call the negative of that the normal vector, and then south would be mostly up instead.

In any case, within the reference frame of earth that seems to be a bad definition. Contrary to popular belief, I am pretty sure that Australian's look up at the sky, not down.

But if you define "up" as the direction opposite to where gravity pulls things (which very much makes sense) then there is no possible situation in which north being up would be correct either. A compass needle never points up. You are mounting a map of something horizontal onto a vertical surface, it is just as correct - or depending on the alignment of the wall arguably even more correct - to put east up. You can only ever get at most two directions correct, after all.

I don't think it uses some special type in any way. Rather, if you use sxml to build html in scheme and have a node in there that is a string, then the natural way to serialize this sxml into html will be to safely quote the string. Afterall, if you wanted html tags to be preserved and interpreted in the output, you would first parse the string into sxml and put that into your document. This is the difference between working with structured data vs. plain string interpolation.

But of course this only applies when you use sxml. Artanis apparently can also use plain strings or templates as responses, in which case you will have to take care of safely encoding things too.

Yes it does, but I don't think the special remote supports the importtree feature, which would be necessary for this.

In an ideal world the rclone special remote would support git-annex' importtree feature. Then you could periodically run `git annex import <branch>:<subdir> --from <sharepoint/dropbox-remote>` to "pull" from those remotes (it is not really a pull as you aren't fetching version-controlled data from those remotes, rather you are importing from a non-version-controlled source and record the result as a new revision).

Unfortunately this is not (yet?) supported I think. But you could also just do something like this: `rclone copy/sync <sharepoint/dropbox-remote>: ./<local-directory> && git annex add ./<local-directory> && git commit -m <message>`.

Depends on the cloud storage provider, I think. The best chances are with those that support the more standard protocols like S3, webdav, sftp, etc.. A relatively new development is the special remote built into rclone, which should be better maintained than some other third-party special remotes and provides access to all rclone-supported remotes.

I had tested a git-annex repository with about 1.5M files and it got pretty slow as well. The plain git repo size grew to multiple GiB and plain git operations were super slow, so I think this was mostly a git limitation. DataLad's approach of nested subdatasets (in practice git submodules where each submodule is a git-annex repository) can help, if it fits the data and workflows.

> NFS is a specific networked filesystem.

NFS is a set of protocols for networked filesystems. You can just as well implement an NFS server that "implements storage based on rat trained to push a button in reaction to lights turning on". Some people even argue it is a better way to do it than FUSE, because you get robust clients on most platforms with included caching out of the box. E.g. this is a library for building such a NFS server: https://github.com/xetdata/nfsserve

Well, it is more than a handful, that was the only point.

You seem to be conflating Anaconda with the conda ecosystem. This package is from conda-forge, which is a community project sponsored by Anaconda but otherwise unrelated to it.

I couldn't care less for Anaconda, but with conda-forge and pixi there is a decent general purpose and language-agnostic package management tool for development purposes in the conda ecosystem.

Hadn't heard about that before, looks interesting. But AFAICS mise focuses on installing tools, not actually all dependencies. It integrates with the languages dependency management tools, which doesn't help you if the language doesn't even have one or the integration wasn't written yet.

I'd rather see more adoption of guix for this purpose. It is a single package manager with a functional approach that allows for introspection of all dependencies (down to the bootstrap toolchains used to build the bootstrap toolchains that build your toolchains, which is something that AFAIK no other package manager except for nix can do), has a fairly large package repository, straightforward locking, actually tested packages, and very easy build recipes (unlike conda-forge...).

What does it change? Conda-forge users are users of the conda ecosystem. You suggested there is only a handful of those that use it not for python, I provided a counter point.

Or did I misunderstand you and what you meant with "conda" was either anaconda, or conda-the-software? But then the comment about Python doesn't make much sense.

A single one of the gfortran packages released about 20 hours ago already has 362 downloads, so I think it is safe to say that the non-python users of conda-forge are more than just a handful.

If you don't need it that's fine, no one is stopping you from using PyPI and uv instead. But for some that is not a replacement.

And yes, some things about conda(-forge) could be described as bloated. I particularly dislike the convoluted packaging process.

It is always tradeoffs and deciding based on your own use cases. E.g. if you want to distribute tested packages to users of your software then both conda-forge and PyPI are ill-suited for you. They (and most other package managers) do install-time dependency resolution, so the installation cannot be guaranteed to be tested as working at all. Some package managers do that better, so is conda-forge and PyPI obsolete now?

So with a fresh installation of one of those alternative conda clients and no user intervention it won't happen, right? On top of that you can block access on the network level as well.

Sure, when your employees are outside of the corporate network they can still download stuff from the default channels, but in the end it is no different than any other license violation they could do. At least with Anaconda there is a semi-effective fix.

Do you have an example for a package on conda-forge that actually does this? I can only find a vague announcement from 2021 that the "defaults channel is now dropped when building conda-forge packages", as well as statements that the conda-forge repositories are considered incompatible with the defaults channel and having both enabled is an unsupported configuration. Access is blocked on the network level anyway.

Anaconda != the conda ecosystem != Python

Everyone who is comparing Anaconda and conda to Astral and uv is missing that the conda ecosystem is language-agnostic while uv is python specific. uv won't help you install gfortran, for example. It is not a replacement, unless you only do python (and use at most common non-python libraries that are available on PyPI).

On the other hand you don't have to use anything associated with Anaconda to use the conda ecosystem. Alternative package managers like mamba and pixi rely on the conda-forge channel instead. Pixi in particular (https://pixi.sh/) is sort-of the uv for the conda ecosystem workflow-wise, and works pretty well if you want that.

My point was that you don't have to take a photo of a receipt to run into this issue, actual machines specifically build to digitize receipts and other documents already made this kind of mistake.

No idea if this can happen with what modern smartphone cameras do to photos. If "AI" is involved then I would expect such issues to be possible because of the basic nature of them being random generators, just like how LLMs hallucinate stuff all the time. Other "enhancement" approaches might not produce issues like this.

Worse, Xerox scanners specifically meant for digitizing documents have changed text for a long time. The compression algorithm they used (I think even in the default settings) sometimes replaced e.g. 6 with 8, and similar things. See: https://www.youtube.com/watch?v=7FeqF1-Z1g0 (german, but there should be news articles from back then in english as well, somewhere)