• 371 Posts
  • 4.72K Comments
Joined 2 years ago
cake
Cake day: July 7th, 2023

help-circle



  • Mirroring is exactly that: a copy

    If the thing you are mirroring does something you don’t like, you can’t stop. Literally imagine standing in front of a mirror and trying to stop the reflection from doing something you don’t like. Not happening.

    The thing about git is that it keeps all history, even in a force push situation, unless they actively clear previous history, which is… difficult.

    What you can do is lag proxy whatever the main branch is to catch it in time, or just keep revisions of your mirror that you script and tag yourself. It’s like a daily backup you can go back and look into.

    It’s going to waste a ton of space and time, but it would effectively create a stop-loss on someone nuking history, which generally is just not a thing that people do because it’s entirely stupid.




  • Gonna have to stop you here and downvote this…this is a horrible idea for a lot of reasons.

    1. There is a reason that a “distro” is a distro. All the components fit together and make a cohesive environment. Providing privileged access to whatever the base is to operate as if it were simply some tool running will 100% break the host OS in time. It’s not even a question.

    2. The abstractions of tools in tools on top of tools is just stupid. The effort needed to manage, recognize, and log where the interactions happen is just absolutely insane.

    3. Simplicity in operation ties into #1. New users would have no idea WTF is even going on here, would find no docs to help them if they run into trouble, or find any other users who are running the same combo of stacks-on-stacks to be able to even attempt to help them out. Advanced users would be able to just pick up a tool from one distro, and drop it another. Makes no sense in either case.

    4. Recovery: should something bad happen, you’d have ZERO way to even attempt to fix it. Again, containerized tools would be make operative changes to the Host OS, and any tools with the Host would be useless to repair them, because they’d only be expecting to work within their own ecosystem…again, what makes a distro distinct.

    Here’s a simple example: I run whatever Host OS, and then I go and run another container OS that intends to operate on my Host, BUT, it’s missing a GCC version that is expected. You poke around a bit, and in an attempt to solve for a missing dependency, now your host gets an incompatible GCC version installed into itself and gets borked.

    No coming back from that in any simple way.

    Again, who is this intended to appeal to?

    Edit: Also, just reading the end, this is like Homebrew with extra steps and more stupidity.


  • You will immediately run into issues with delivery without an upstream partner or other known IP space, but ignoring that:

    Keila is a pretty modern tool meant pretty specifically for this.

    Ghost (the blog platform) has a lot of this stuff built-in, plus can host a static view of each.

    ListMonk has been around a bit, but is more for campaigns I think.

    Odoo community version has some pretty solid tools that will make it all super simple, plus has some other good tools. It may lack some of the deeper integration features, but again, it’s dead simple and has a solid interface.












  • Labels/Tags are a product feature, not part of email standards. Meaning: it’s not a thing when looking at the raw mail server data.

    Each product handles this in their own way, and the tool being used to export your mail from one host/product to another would be what is handling that, if at all. Gmail probably just uses folders because that is part of the structure a mail server would have.

    I believe Proton’s import tools handles this correctly from Gmail using both labels as folders and preserving tags, but I believe Thunderbird just puts them in folders as is standard.

    You can double check by looking at the raw data exported from any mail service. You could probably easily write a quick script to handle getting tag info and applying it yourself, though it could be quite slow.