@technom - eviltoast

TechNom (nobody)

  • 0 Posts
  • 211 Comments
Joined 1 year ago
cake
Cake day: July 22nd, 2023

help-circle



  • He didn’t just wash off his hands. When asked in an interview about a moderator who edited a trans user’s profile to intentionally misgendering them (yup, even that’s not off limits for their mods), he justified it saying that ‘It’s not like using the N-word or something’. (For context, the n-word itself was innocuous. It gained notoriety due to its misuse by bigots like this).

    There are several such examples - repeatedly even after being called out. I don’t belong to any diversity groups. But I don’t care if they make the world’s best operating system. I will stay well away from it if only to avoid any interaction with such a group. They’re a bit too happy about harassing people (not just transgenders either).


  • This is clearly intended as an alternative to submodules.

    An alternative, not a replacement. Vdm is specifically designed to track code dependencies. There are use cases like monorepos where vdm won’t work.

    Neither does Git though. I’m not really sure I follow your point.

    Git does track submodule history unlike vdm.

    By default, vdm sync also removes the local .git directories for each git remote, so as to not upset your local Git tree.

    Git submodules don’t delete those .git directories. It uses them.

    If you want to change the version/revision of a remote, just update your spec file and run vdm sync again.

    This is not how git submodules or subtrees work.

    vdm does depends on git being installed if you specify any git remote types

    Support more than just git and file types, and make file better

    Git submodules and subtrees don’t support anything other than git remotes.





  • While I understand your point, there’s a mistake that I see far too often in the industry. Using Relational DBs where the data model is better suited to other sorts of DBs. For example, JSON documents are better stored in document DBs like mongo. I realize that your use case doesn’t involve querying json - in which it can be simply stored as text. Similar mistakes are made for time series data, key-value data and directory type data.

    I’m not particularly angry at such (ab)uses of RDB. But you’ll probably get better results with NoSQL DBs. Even in cases that involve multiple data models, you could combine multiple DB software to achieve the best results. Or even better, there are adaptors for RDBMS that make it behave like different types at the same time. For example, ferretdb makes it behave like mongodb, postgis for geographic db, etc.