#Tag · bonfire.cafe

I am about to give a workshop about #reproducibility in the context of #ROOT #technology using #doomemacs #emacs (cf. https://doi.org/10.5281/zenodo.17157587).

Now I am wondering how I can make sure that the participants have installed all necessary programmes? I came up with a little test script: Please #help me to improve the script testing for edge-cases; execute the script and let me know if it works and/or what can I improve: https://gitlab.git.nrw/-/snippets/113

Thank you! #retoot #BoostoK

Zenodo

Resilient Technologies. Why Decades-Old Tools Define the ROOT of Modern Research Data Management

Research data management (RDM) today is characterized by a multitude of new platforms and specialized software solutions. These innovations are undoubtedly important, but they also involve risks: short life cycles, proprietary dependencies, and limited sustainability. In contrast, there are tools that have existed for decades and have proven to be remarkably resilient. These “resilient technologies” are distinguished by longevity, openness, interoperability, and the support of active communities. Examples include Emacs (established in 1976 as a highly customizable editor), awk (1977) for efficient text and data processing, sed and grep (indispensable in pattern recognition and transformation since the 1970s), as well as perl (1987) as a flexible scripting language for data pipelines. In the field of documentation, LaTeX (1984) stands for sustainable, reproducible, and platform-independent text processing. For the automation of complex workflows, make (1976) has proven its worth, while rsync (1996) remains unrivaled as a robust tool for data backup and transfer to this day. This is complemented by curl (1997), which has enabled stable and universal data transfer over the internet for decades. This three-poster series argues that decades-old, community-maintained tools form the ROOT of sustainable research data management—Robust, Open, Ongoing, Time-tested. The Concept/Meta poster motivates the idea of “resilient technologies,” tracing its lineage from literate programming and the Unix philosophy to contemporary RDM/NFDI practice. It introduces the ROOT badge as a compact signal for tools that are transparent, composable, well-documented, and maintained across years. The Main poster translates the concept into practice by mapping resilient tools (e.g., Emacs/Org-babel, Make, curl/sed/awk/grep/diff, cron, tar/rsync, SQLite, LaTeX, find) onto the research data life cycle (planning, production, analysis, archiving, access, re-use). It highlights simple, inspectable patterns—small steps that chain together into pipelines you can audit, version, and rebuild long after fashions and GUIs change. The Source poster closes the loop by disclosing the full build of the posters themselves: a reproducible, text-first publication that can be re-generated from a single source using the very tools it advocates. Together, the trilogy provides a coherent “why–what–how”: a rationale for resilience, a concrete mapping to RDM tasks, and an executable artifact that embodies the approach. The intended outcome is pragmatic: lower maintenance burden, higher reproducibility, and infrastructures that improve with age. The Focus poster has the main, meta and source poster combined and one section with focus areas.

Lukas C. Bossert

@lukascbossert@mastodon.social · 2 days ago

I am about to give a workshop about #reproducibility in the context of #ROOT #technology using #doomemacs #emacs (cf. https://doi.org/10.5281/zenodo.17157587).

Thank you! #retoot #BoostoK

Zenodo

Resilient Technologies. Why Decades-Old Tools Define the ROOT of Modern Research Data Management

tusharhero

@tusharhero@mathstodon.xyz · 6 days ago

@divyaranjan Here is a demo of the new canvas API:

#emacs

tusharhero

@tusharhero@mathstodon.xyz replied · 5 days ago

@divyaranjan yet another demo, this time Minad ported #Doom to #GNU #Emacs. ( #Doomemacs?)

https://github.com/minad/doom-on-emacs

GitHub

GitHub - minad/doom-on-emacs: Doom on Emacs

Doom on Emacs. Contribute to minad/doom-on-emacs development by creating an account on GitHub.

algernon e. coyote

@algernon@come-from.mad-scientist.club · 3 weeks ago

TIL di( is a thing, and it is really useful. The whole di thing is great.

#DoomEmacs #vim

hardtech.fts

@hardtech@corteximplant.com · last month

In 2026, I want to change my OS. I'm hesitating between

Arch
Devuan
Gentoo
Guix and
Void

Things to consider:

I've already installed and used Arch some years ago; I'm considering Artix, excluding the s6 init (I'm not prepared for this one);
gentoo and Guix are probably the most complex distros1
Void is certainly the most comfortable choice.
It's to install in real hardware: Intel i5-7400 3ghz, ssd 1to, 32gb ram, nvidia geforce 1060 3gb. Yes, I want to play light videogames sometimes Main purpose would be to learn Linux, Web, writing MarkDown and Org, zettlekasten organisation, etc...
#linux #archlinux #ArtixLinux #devuan #gentoo #GuixSystem #voidlinux #emacs #doomemacs #vim #orgmode #orgroam #vim #HelixEditor #zettlekasten

1: complex ≠ complicated

algernon e. coyote

@algernon@come-from.mad-scientist.club · 5 months ago

I upgraded my #DoomEmacs, and now dired-hide-details-mode fails to enable by default.

(add-hook 'dired-mode-hook #'dired-hide-details-mode)

This used to work. It gets added to the hook, and yet, when I visit a directory, it's not active.

This is making me unreasonably angry.

chesheer

@chesheer@mastodon.bsd.cafe · 10 months ago

I've been using #Emacs for the last couple of months now for all my daily work (I'm a translator, not a programmer) and here's a thought.
Of course, I stumbled upon rather contrasting recommendations:
1) Don't use vanilla, use #DoomEmacs or #Spacemacs. Preferably Doom. Well, I tried this in the past, but it didn't stick. It''s everything and the kitchen sink, but you generally don't know if you really need all this. So you study Doom, not Emacs. I might get back to it in the future. I did prefer Spacemacs, though (aesthetically).
2) Use vanilla and spend ten years building your own config. This sounds fairly reasonable, because you naturally learn the program itself, not its plugins. But it's a huge timesink when you start to "build your own Emacs". So you'd end up with DoomEmacs, but badly written, slow and constantly breaking on every update.
I went with the second alternative and here's what I got for my personal usecase:

me@desktop:~$ grep "use-package" .emacs.d/init.el | wc -l
8

Eight packages. howm, inkpot-theme, which-key, avy, counsel, general, annotate, markdown-mode. I didn't even bother to make annotate work for now, so it's 7. And I don't really use avy, so it could be 6.
That's all I need for now. For several months I haven't had a moment yet when I thought that I need something else or that my workflow is getting somewhat cumbersome.
Of course, this doesn't mean that my setup is perfect. But my point is: configuring your own Emacs could be way easier than you might think (depending on the workflow), and you probably don't need to fight a bazillion packages waging civil war in your config file.