• 0 Posts
  • 60 Comments
Joined 1 year ago
cake
Cake day: July 23rd, 2023

help-circle
  • All of these packaging systems have plenty of tutorials. Speaking from experience, many maintainers were not developers when they started maintaining packages for distros other than the official distros. I have worked with several maintainers who do work in tech and know socially several who had no background. This could be a great place for you to start!

    You bother because FOSS is as much paying it forward as it is getting shit for free.



  • I like how simple it is. It’s made distrohopping very, very simple for me over the years. The only pet machines I have are my actual dev boxes. The rest are cattle I manage with other tools. Galaxy has also made it much simpler to consume other Ansible which used to be really annoying.

    I’m on the fence about Nix. When I first saw years ago it was yet another package management system. I’ve seen enough interesting things with it now that I’ll probably try it out the next time I want to rebuild my configs from scratch.


  • I really like Ansible and have used it for my personal dotfiles for years. I don’t think it’s a silver bullet and I’m aware of a lot of the criticism. Containerization or immutable infra solves more production problems so I don’t really use it much at work.

    At least in the devops/SRE circles I work in, we know there are different tools for different jobs. While we might fight about which is the best, I haven’t seen the ossification you’re describing.




  • If a repo is very popular, it should have a lot of forks. The higher the upstream popularity, the higher the downstream popularity. When a dev makes a claim that there are a ton of malicious forks stealing IP, we can vet that claim by looking at the forks that respect the upstream. Big projects have a big community with big forks with many stars. The popular downstreams drive traffic to the upstream.

    In this case, we have a couple hundred direct forks. That’s not a ton. Out of those, only three have stars. All of them only have one star. At face value, that could imply a few things: the repo is not very popular, the community is centralized around the upstream, or something else along those lines. Comparing this to other open source projects, our initial conclusion is that this is not a hugely popular repo and does not get a lot of development outside of its incredibly niche community.

    Occam’s razor is a tool, not objective truth. Based on the facts as we can see them, this focus on forking from the dev is much more indicative of a burnout spiral, incredibly common in the FOSS community, than nefarious actors. If we see receipts, eg a collection of takedown requests on malicious forks attempting to claim ownership of the code, our analysis falls apart. That’s still a possibility, however remote.


  • There were forks that wanted to hide the fact that they were Floorp forks, forks that did not want to contribute to Floorp at all, forks that used the code for life and just changed the name of Floorp, and many other forks were born.

    There are three visible forks that have any stars. All of them have one star. You’re telling me that a project that is so widely and maliciously repackaged has no normal forks with more than one star? Is this tech that only bad actors want to use and has no following in the open source community?

    Where are these evil forks, how do we actually know they’re forks, and why are they still up if they’re breaking license?

    Edit: Here is a fork with 200+ stars that isn’t a direct GH fork. Given its premise is an opinionated and branded Floorp, is it morally wrong for its maintainers to not contribute to Floorp (assuming they don’t only for the sake of argument)? Does your answer apply to fediverse server owners (eg Mastodon, Lemmy) whose premise is hosting an opinionated and branded instance often explicitly without the technical skill to suggest patches?



  • The ostensible point is to prevent resellers from platforming your code. SSPL is an answer to, say, AWS offering your product much cheaper than you can. RSAL seems to be Redis spinning their own SSPL, BSL, whatever bullshit license because they’re not happy with the existing faux open source cloud licenses that prevent platforming.

    There really isn’t a good way to handle this from an open source perspective. Cloud majors can and will undercut the fuck out of anyone to establish dominance. Ideally you’re providing a better support experience or working with them (until they decide to kneecap you) to maintain your business. Previously Redis had an paid tier that had functionality not available at the OSS level. I think that’s also legit.

    I personally loathe the compliance issues these random shitty fucking licenses throw and don’t think trying to claw back business from majors is the right approach. The little guy is going to follow the path of least resistance which means you’ve made your software enterprise only.











  • I’m going after the right paradigm. There’s an attitude in FOSS that if you don’t blindly follow everything someone from FSF says (or someone who looks up to Stallman), you’re a bad person. See my first pull quote from above. If you’re going to say something like that and not offer solutions to the pain points of your customer journey, you deserve ridicule (“you” being the author and the slrpnk user who dropped the important first part from their pull quote). The only reason I commented was because of the complete mischaracterization of people like myself, who I know many of, where the endowment effect is a more realistic description than this narcissistic spin.

    Your argument is also very tenuous given the outage I called out. I code every day. Literally not figuratively. I code on at least two different devices work days and sometimes mobile (not laptops) weekends. I require a stable remote. An outage of 170hr is not something I care to handle. That’s just me solo. If I wanted to coordinate more than me, it would be a complete dealbreaker.