• 0 Posts
  • 200 Comments
Joined 2 years ago
cake
Cake day: November 23rd, 2024

help-circle









  • And just to be very explicit why this is an issue: each time the package is upgraded through an automated update, the PKGBUILD may change (e.g. to adapt to different dependencies, file structure, etc introduced with new app version).

    That also means an AUR maintainer can smuggle in malware with any of those updates, even if you checked the original PKGBUiLD when you installed. And, anyone can request taking over maintenance for unmaintained packages, so it can even happen if the original maintainer was benevolent.

    Always check PKGBUILD files on upgrade, even if just a glance. If I remember correctly yay had a function to always show you PKGBUILD diffs before updates, not sure if that was automatically enabled.


  • hoppolito@mander.xyztome_irl@lemmy.worldme_irl
    link
    fedilink
    English
    arrow-up
    3
    ·
    3 months ago

    Was it already with the same text/emoji combo?

    Cause that particular tears of joy emoji only became standardized in Unicode 6.0, 2010. It was presumably around a bit before that but nobody except the Japanese really did a lot of emoji stuff much before that (iirc Google and Apple only started adding the first emoji to their keyboards 2007-08).

    Either way would find it very interesting if somebody was already using the emoji way before that, or the text area of the picture went through multiple iterations.


  • isn’t the better solution not to accept PRs from unknown / untrusted sources

    I think that’s partly the point of this exercise - if they find a meow they now know this is an untrusted source.

    Because it’s pretty easy to say ‘ignore untrusted sources’ but when you’re maintaining an open source repo (especially if it’s still pretty small/new) this detection is part of the cognitive burden. Almost every contribution will technically be from an unknown source for a long time, until, if you’re lucky, some drive-by contributors turn regular.


  • hoppolito@mander.xyztolinuxmemes@lemmy.worldGnome Slander
    link
    fedilink
    English
    arrow-up
    2
    ·
    3 months ago

    I think that’s the perfect choice of distinguishing phrases.

    KDE is very customizable (perhaps too much for more casual users) while Gnome is hackable with the extension system - but it will always feel a little more tacked on, be a little less stable, prone to upgrade breakage, etc.

    As a corollary to OPs argument, there’s also a reason Niri and Cosmos didn’t stay Gnome extensions.

    (But at the end of the day, if the Gnome experience niche works for you, more power to you.)







  • While the above is a little more focused on front-end/web projects I think one thing to keep in mind generally is also to meet the user where they are, or rather where they expect. E.g. if you create a tool/plugin for vim, users will be thankful for having a vimdoc for reference. If you create a command line tool, a man page will be helpful for quick lookups.

    I know that many projects today (especially when first getting set up) focus on a presentable readme but in many cases there are tools to automatically adapt this markdown text to the generally preferred documentation style and location.

    Don’t have to focus on perfection first but just having a pipeline set up which can then be iterated on over time.

    For a more advanced approach I think you can get a lot out of understanding the principles of the Diataxis framework - but this is also larger up-front effort.