What's the state of the art on readying a FOSS project to be cited in scientific papers?
-
What's the state of the art on readying a FOSS project to be cited in scientific papers?
Mostly python, though not published through pypi, if it matters.
cc @dartar
-
Esther Payne :bisexual_flag:replied to Luis Villa last edited by [email protected]
@luis_in_brief @dartar I don't know about state of the art, but Zenodo will work with GitHub and assign a DOI number to it.
This is what we did with our testing software for our multicast comparison experiments for Fed4fire+ which was part of @EC_NGI
librestack/fed4fire: v0.0.1
Comparing Performance of IPv6 multicast and unicast for software updates F4Fp-SME-COD210601-05 All software has bugs. All connected devices require software updates to be secure – everything from the largest server infrastructure to the smallest IoT device. The network component of a software update is a data transfer. A file or files need to be distributed from a central point to potentially billions of nodes. Presently, in almost all cases, these updates are delivered via unicast. By devices, we do not just mean IoT but the entire infrastructure internet. Routers, VOIP, mobile phones, consumer devices. A device that is connected to a network will at some point require updates. The experiment aimed to show a marked improvement over unicast for this use case so that the application of multicast for other (non-streaming) will become clear. Librecast aimed to show the fundamental difference in thinking between unicast and multicast. Specifically, in comparison to unicast, multicast; uses less bandwidth requires less infrastructure has a lower power consumption has a lower carbon footprint can lower financial costs, both capital and operating costs can make better use of on-demand (cloud) infrastructure has privacy improvements over unicast The network component of a software update is a data transfer. A file or files need to be distributed from a central point to potentially billions of nodes. Presently, in almost all cases, these updates are delivered via unicast. By devices, we do not just mean IoT but the entire infrastructure of the internet. Routers, VOIP, mobile phones, consumer devices. Everything that is connected to a network will need updates. If we can show a marked improvement over unicast for this simple and universal use case, utilization of multicast for other (non-streaming) cases becomes much clearer. Librecast aims to show the fundamental difference in thinking between unicast and multicast. Release for archival on Zenodo along with: Report: https://doi.org/10.5281/zenodo.6470929 Data : https://doi.org/10.5281/zenodo.6382741
Zenodo (zenodo.org)
-
Patrick Lamreplied to Esther Payne :bisexual_flag: last edited by
@onepict @luis_in_brief @dartar @EC_NGI we did have some problems with large blobs in GitHub and the integration with Zenodo. I think that, if there are large blobs, it's at least worth testing and probably needs to be copied manually.
-
Esther Payne :bisexual_flag:replied to Patrick Lam last edited by
Yeah we didn't have blobs. So it was fairly straightforward.
Although after that we left GitHub for #GiveUpGitHub and moved to @Codeberg .
I think it would be awesome to have similar functionality with #ForgeFederation what do you think @RyunoKi
-
Ryuno-Kireplied to Esther Payne :bisexual_flag: last edited by
Thanks for the mention @onepict.
I don't know OTOH whether @Codeberg uses LFS ( https://git-lfs.com/ ) but without it git itself will refuse to check in or out (personal experience).
Since GitHub belongs to Microsoft I'm confident they use something in Azure. https://docs.github.com/en/repositories/working-with-files/managing-large-files/about-git-large-file-storage
I recall from the xz accident that some test files were large. Haven't checked whether they're tracked in git or generated.
I would suggest to talk to @blender people for experience.
-
Esther Payne :bisexual_flag:replied to Ryuno-Ki last edited by [email protected]
@va2lam @luis_in_brief @Codeberg @andre
I didn't realise Zenodo has a rest API. So some way for an extension for @forgejo integration would be cool.