Proposal: Orchestrating MX-snapshot logic with penguins-eggs (Node.js + Bash synergy)

[pieroproietti]

Hi Adrian,

I’ve been following your work for a long time, and I want to start by saying that what you’ve achieved with MX-tools is truly remarkable. MX Linux has set a standard in the community, and its reputation for being a "Swiss Army knife" for users is largely thanks to your wizardry with Bash and system-level tools.

Let me introduce myself: I’m a 64-year-old retiree from Italy who enjoys coding instead of hanging out at the bar or watching construction sites. This is not a "corporate" business for me, though I wouldn't mind earning a few "lire" from it; it's mostly about passion and solving problems.

Let's be honest: at the end of the day, both penguins-eggs and MX-snapshot are the evolved children of refracta-snapshot. We both know the struggle of maintaining those "monolithic" Bash scripts—they become unmanageable "lenzuoli" (endless sheets) when you try to support multiple distros and complex boot scenarios.

I’ve been fighting the "lenzuolo" by splitting the workload: I moved the business logic to Node.js (eggs) and kept Bash for the heavy lifting on the system level.

You can check my repository here: penguins-eggs.
If you have a moment, take a look at these specific parts:

• Distro class (environment detection)
• Pacman class (package manager abstraction)
• Ovary class (the "lenzuolo" I'm refactoring)

My idea is simple: instead of duplicating our efforts, why don't we separate the "Brain" from the "Muscles"?

• The Brain (eggs / Node.js): Handles the high-level orchestration, CLI, and exclusion patterns. It decides what to do and when.
• The Muscles (Your Bash scripts & Templates): You maintain the operational backend and the boot templates—the stuff you’ve already mastered for MX and Arch.

Instead of "drowning" Bash in Node.js, I use Node as a clean orchestrator that triggers specific, atomic Bash scripts. I’d love to see eggs acting as a modern frontend that leverages your battle-tested scripts and templates as a backend.

What do you think about defining a common ground? It would be a way to honor the legacy of Refracta while building a universal remastering tool that doesn't reinvent the wheel every time.

Best regards,

Piero (artisan@penguins-eggs.net)

[AdrianTM]

Thanks Piero for writing to me.

Let's be honest: at the end of the day, both penguins-eggs and MX-snapshot are the evolved children of refracta-snapshot.

Let me address this misconception because it's been floating around (and even snuck into our documentation at some point). I've never seen Refracta, from what I can find online the first release of Refracta was from 2013-2014, I started to work on a "remastering" script since 2008, I even have an old remaster.sh script on Github from 2011 https://github.com/AdrianTM/remastering-script/blob/master/remaster.sh (but the script actually predates my use of Github) ultimately this GUI tool is a outgrowth of that. Last year when somebody mentioned the same misconception I took a quick look at refracta-snapshot and it actually uses different concepts (Refacta script did a lot of rsync-ing instead of bind mounts as we do) so I don't they are genealogically related, so it's just two tools that do similar things without one being the parent of another as far as I can say from a quick look at the code.

It would be a way to honor the legacy of Refracta while building a universal remastering tool that doesn't reinvent the wheel every time.

Well... I'm sure they are a fine distro, but I don't particular feel any need to honor them especially that I don't think I've ever booted that distro and people are claiming this tool I wrote got inspired from them when I clearly have a repo that predates Refracta by a number of good years and have emails between me and anticapitalista, of antiX that date back to 2008 where we were talking about the technical details of the remastering script.

Here's a discussion I had with anticapitalista (who himself was initially confused) about this Refracta issue on the MX Linux forum about a year ago: https://forum.mxlinux.org/viewtopic.php?p=823274#p823274 or this https://forum.mxlinux.org/viewtopic.php?p=823730#p823730

As for the technical request, I will have to think about it also might need more info what exactly you propose. My instinct is that I am not interested to add a Node.js dependency to this or split too much functionality, I'm actually moving away from the installed-to-live bash script (initially written by BitJam dev of antiX when I was struggling doing the bind mount cleanup in Qt -- can't swear that script was not influenced by Refacta in any way because I didn't write it myself, but its functionality was first implemented in Qt by me and BitJam just volunteered to do it cleaner in self-contained bash script), I removed that particular dependency in Arch for example, so I think I'm moving the opposite way you are suggesting, consolidating, not splitting functionality. But I'm open to ideas and suggestions and standardization, I'm a bit unclear how we could coordinate and what you could use from my app and what I could use from yours (even if we ignore that issue of honoring Refracta).

Thanks,
Adrian

[pieroproietti]

Hi @AdrianTM, thanks for the answer.

Regarding the origins: I started my journey in 2016/17 exploring what was available—first Remastersys, then Systemback, and eventually Refracta. During that process, I came across your tools as well and, in my mind, I mistakenly assumed a common lineage.

In any case, I quickly realized that the 'bind mount' approach you used was far superior to the rsync method for saving time and reducing disk I/O. That technical choice was a key insight for me.

But history aside, what matters to me is presenting my idea and seeing if we can find a shared path forward.

With penguins-eggs, I’ve tried to support as many original distributions as possible (currently: Alpine, Arch, Debian/Devuan/Ubuntu, Manjaro, and openSUSE). As you can easily imagine, maintaining compatibility across all these bases with every new release is a nightmare.

I understand you are moving towards a pure Qt implementation to phase out Bash scripts. My goal isn't to challenge that or force a specific technology, but to see if it's possible to standardize some of the underlying logic. This would make things easier, even if implementations (Qt vs. Node.js vs. python or other) remain different.

If you are interested, I can work on a more detailed description of the logic and processes I’m currently using. We could then look at it together to see if there’s a way to align our approaches and find a common ground.

[AdrianTM]

One potentially alignment that we could work on could be the exclusion file. But otherwise I'm a bit unsure how we could standardize things or what would the the payout if we standardize the logic in our separate tools. What would be the end goal?

[pieroproietti]

I don't have a completely clear roadmap yet either, but as we’ve seen, remastering Debian or Arch shares the majority of the same underlying logic. The idea is simply to consolidate that shared code into a dedicated, high-performance engine.

I’ve been tinkering this afternoon—leaning heavily on AI—and started building Vitellus (Latin for "yolk"). It felt like a fitting name for the core of an "Egg."

It’s just an experiment and a rough idea at this stage, so absolutely no pressure. If it’s something you find interesting, I'm happy to dive deeper; if not, no worries at all!

You can see the early progress here: https://github.com/pieroproietti/vitellus

[pieroproietti]

Just a couple of updates: I’ve completed the project skeleton and renamed it to oa. Yesterday was just experimental code, but the current version can already remaster and boot a live system—it's incomplete, of course, but it works!

Today I focused more on the structure and philosophy. To be honest, this plan is a bit too big for me to handle alone, but I think it’s something really interesting to explore together.

I put my exclude.list, in default and suppose are equivalent to yours.

[pieroproietti]

Hi Adrian,

Just wanted to share a quick update now that my concepts are more defined. I achieved a working remaster tool using only 73Kb of C code, zero-copy via overlayFs and utilizing JSON to handle the plans and actions.

Here is the manifesto if you'd like to take a look: https://github.com/pieroproietti/oa/blob/main/MANIFESTUM.md

I'll stop here so I don't spam the conversation, but I hope you find this approach interesting.

Anyway thanks for all! :-)

[AdrianTM]

Thanks, will take a look, I promise, a bit busy this days, but I will get to it.