• 1 Post
  • 65 Comments
Joined 2 years ago
cake
Cake day: June 13th, 2023

help-circle

  • It’s worse. My music is on Spotify - while I would no longer meet their minimum for payments, even before that change they refused to pay me or provide stats until I provided a twitter or Facebook page/IG page, none of which I have - despite publishing through an established publishing company who could absolutely handle payments and play stats.

    Spotify is cancer.






  • It was highly contentious for a number of years - largely because it had a lot more functionality and touched more parts of the OS than the init systems it was designed to replace. It was seen as overzealous by the naysayers.

    I was in the never system-d camp for a long time because I felt like my ability to choose was being removed. Even some distros that provided alternate init systems eventually went systemd-only.

    But I’ve come around - it’s fine, good even - though ultimately I had no choice or say in it.

    It’s very straightforward and easy to write one’s own units. It’s reasonably easy to debug and often helpful when something isn’t working as expected.

    Like all things in the world of software, many folks are going to try (and eventually succeed) to make a better mousetrap.

    This particular init system’s design goals seem (at least to me) to indicate a focus on small, embedded and/or more secure systems where the breadth of tools like systemd are a hindrance.



  • I really appreciate your response. It’s incredibly helpful and deeply thoughtful. Thank you.

    What comes next is not directed at you but rather provides some other color based on a few things you touched on.

    I worked for the guy. He gets no slack from me. He changed my life in many ways both wonderful and not. And while it’s unlikely I’d work with or for him again he was a net positive in my life.

    I don’t see product the way he sees product which is exactly as you note: it’s for him. Some of that “for him” approach has resonated deeply with the OSS community and still does. He changed Cloud Computing in the best of ways. He’s a giant. And we’re lucky he’s around.

    This small ghostty issue (and some others I can’t recall now) was emblematic of our core disagreement about how we build systems for a broader user base. That’s why I said I get their PoV but disagree with it. I think it would be fair to say using the product reminded me a lot about this particular tension. Reading the GitHub issues even more so. That’s wholly on me.

    I am thankful to ghostty for helping me explore many more options. I had been using iterm2 on my laptop and struggling to find something I liked on my Linux workstation. Checking out the new hotness after all the hype still resulted in a net positive.

    Nevertheless I am genuinely happy it’s working for you and, again, thanks for your kind and calm response.


  • Yep - but seeing the thread about it in their github repo was also a turn off. I don’t have to do it with other clients.

    I also believe that has to happen on each server - and we’ve got a lot of servers. I’m not particularly keen on needing to change anything to get my terminal emulator to, well, work.

    While I get the ghostty team’s PoV - I don’t agree with it.


  • Ghostty has lots of issues ssh-ing into remote systems that aren’t on the bleeding edge.

    I couldn’t get it to work reasonably well enough for me and tried a bunch of others. Currently using Alacritty on both my Linux desktop workstation and Mac Laptop.

    I use Zellij anyway and it has all the tab/pane/floating window support I was looking for.




  • Hoping this question is in good faith.

    I think that depends on what we mean by “pay.”

    My take:

    If our lives are better/easier/safer/happier than the lives of those who grew out of wrongs committed by those of our own heritage / lineage, then yes, I believe we should endeavour to make their lives better.

    Whether that’s financial reparations, return of property / land, sharing of resources, etc. should be up to communities to work together to decide.

    Put another way, if my good fortune rests on the misfortune of others - even in the past - my personal take is that I am compelled to help where I can.

    Sometimes that’s a simple as voting for the thing that benefits me less than others or me not at all because it aids those who need it most.

    So yeah, we should “pay” but “pay” can mean so many things.

    That’s just me.






  • It depends on many factors including:

    • visits of individual sites
    • requirements of each site (memory, I/O, persistent storage, ephemeral storage, caching, databases, etc.)

    So you’re right that you make an initial guess and go from there.

    Many tools/sites/projects will have minimum system requirements and you can get an idea of minimums using those stats. Some frameworks might even have guidelines available. The one I use most often for example has a configurable memory footprint. So that’s a datapoint I personally use.

    If they’re all the same type of site (example Ghost blogs) using the same setups then it’s often less intense since you can pool resources like DBs and caching layers and go below minimum system requirements (which for many sites include a DB as part of the requirements).

    Some sites might be higher traffic but use fewer resources, others might be the inverse.

    Then there’s also availability. Are these sites for you? Is this for business? What kind of uptime guarantee do you need? How do you want to monitor that uptime and react to needs as they arrive/occur?

    The best way to handle this is in a modern context also depends on how much and what style of ops you want to engage in.

    Auto-scaling on an orchestration platform (something like K8S) or cloud-provider auto-scaling of VMs or something else? Do you want deployments managed as-code via version control? Or will this be more “click Ops”. No judgement here just a thing that will determine which options are best for you. I do strongly recommend on some kind of codified, automated ops workflow - especially if it’s 25 sites, but even with just a handful. The initial investment will pay for itself very quickly when you need to make changes and are relived to have a blueprint of where you are.

    If you want to set it and forget it there are many options but all require some significant initial configuration.

    If you’re ok with maintenance, then start with a small instance and some monitoring and go from there.

    During setup and staging/testing the worst that can happen is your server runs out of resources and you increase its available resources through whatever method your provider offers. This is where as-code workflows really shine - you can rebuild the whole thing with a few edits and push to version control. The inverse is also true - you can start a bit big and scale down.

    Again, finding what works for you is worth some investment (and by works I don’t just mean what runs, but what keeps you sane when things go wrong or need changing).

    Even load testing, which you mentioned, is hard to get right and can be challenging to instrument and implement in a way that matches real-world traffic. It’s worth doing for sites that are struggling under load, but it’s not something I’d necessarily suggest starting with. I could be wrong here but I’ve worked for some software firms with huge user bases and you’d be surprised how little load testing is done out there.

    Either way it sounds like a fun challenge with lots of opportunities for learning new tricks if you’re up for it.

    One thing I recommend avoiding is solutions that induce vendor lock-in - for example use OpenTofu in lieu of something like CloudFormation. If you decide to use something like that in a SaaS platform - try not to rely on the pieces of the puzzle that make it hard (sticky) to switch. Pay for tools that bring you value and save time for sure, but balance that with your ability to change course reasonably quickly if you need to.


  • As per my other comment - the algorithm is only part of it.

    A big aspect however is the slickness and ease-of-onboarding for mega-Corp apps. It’s a thing that would relatively easy to begin work on.

    I’ve seen first hand the amount of time and money even growth-stage startups spend on onboarding and have lots of first-hand reports from peers at the big girls - it’s a critical part of success. Make it easy to get started and easy to stay using.

    It’s missing from most fediverse experiences. Pixelfed being a serious contender for an on-boarding rethink.

    “time-to-value” - we want that as low as possible.