• 0 Posts
  • 111 Comments
Joined 2 years ago
cake
Cake day: June 12th, 2023

help-circle







  • Are you really saying “we the developers are going to build this however we see fit, and you the user can go fuck yourself, or else learn how to code and build it yourself”? Is that really the dynamic you’re trying to cultivate here? Seems very welcoming and productive.

    Nope.

    People will volunteer their time how they want, and you don’t get to tell them how to, unless you pay and also say please.

    Your choice, when faced with devs spending their free time not helping your particular goals, is between

    • pay someone to work on your stuff
    • work on it yourself
    • stay on Facebook to get facebook but suffer their dev decisions and be the product they’re selling to advertisers while you do
    • go to another similar setup and hope the features are closer to what you want to trade yourself for.

    None of this should be surprising, given the fediverse is very largely supported by great people donating a lot of time. And remember, they’re not doing it for you specifically, and they’re usually doing it for their own interest or goals.

    You’re going to have to spend some time or money making your particular goals happen; or else suffer someone else’s goals, or be the product they sell, or both.

    I hope you realize it’s not someone denying you stuff; that it’s someone doing what they want with their free time, and it’s only accidental that it impacts you badly.

    Make it better.


  • corsicanguppy@lemmy.catoSelfhosted@lemmy.worldRelease frequency preferences
    link
    fedilink
    English
    arrow-up
    4
    arrow-down
    1
    ·
    edit-2
    10 days ago

    As an end-user (that is, the IT staff that will be deploying/managing things), I prefer less-frequent releases. I’d love to see 1 or 2 releases a year for all software

    The hard floor for release frequency must always be “as security issues are fixed”, and those will rarely be infrequent in our current environment of ever-shifting dependencies.

    If your environment is struggling to keep up with patching, you need to analyze that process and find out why it’s so arduous.

    As an example, I took a shop from a completely manual patch slog 10 years ago to a 97% never-touch automated process. It was hard with approvals and routines, but the numbers backed me up. When I left 2 years ago, the humans had little to do beyond validation.

    The sad news is, the great loss of mentors after Y2K will be seen again after RTO, and we’re not going to fix the fundamental problems that enable longer release cycles in a safe way; and so shorter update cadence will be our reality if we want to stay safe …

    … and stay bleeding-edge. Shifting from feature-driven releases to only bugfix-driven releases means no churn for features, but that’s a different kind of rebasing. It’s the third leg of the shine-safe-slack pyramid; choose 2.








  • resort to static linking. As you always should, actually. :-)

    Tell us you have no concept of enterprise OSes without using those words. Wow, is this particular statement near-sighted and provincial.

    Oh god; it gets worse. This-week’s everything, like support and consistency are thrown out the window because supply chain exploits and random new bugs are just the best things ever.

    This guy needs to talk to an OS security guy. I used to be one, and I could be one in a pinch, but he really needs to find an adult with a clue about the three goals of build and maybe spend a bit of time on an OS support line to learn why his process is the best way to fuck and or breach your system.

    Sorry to rant, but my entire career has been either learning again in/yum-cron why what this guy says is super irresponsible and/or preventing or then fixing the fallout from following this guy’s criminally-bad advice.