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 mean it’s FOSS. Have you considered opening a PR to contribute what’s missing? You can be the change you want to see. I wouldn’t normally comment something like this. Your emphasis on “still” raised my hackles a little bit and led me to ask why you still haven’t made your own.
In case you want to fact check this post, I highly recommend Glyn Moody’s Rebel Code. It’s a nice, fast read and covers all sorts of cool shit. I’d love to see a sequel covering newer events.
(Edit: OP is facetious; mine is only facetious in that it references OP)
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.
There are valid reasons to use one instead of the other. In most cases there isn’t a difference to the end user.
I am still mystified by IDE VCS tools. It’s usually faster for me to do a quick CLI shuffle than use the IDE.
The only other time rewriting history might be bad is when you’re working on a shared branch, which is the point of not rewriting main. If you are working solo on a branch, its history is only what you merge into main so it doesn’t fucking matter at all. If you’re not working solo, maybe you need to adopt a similar process or look at how you’re not working solo. The only time I touch another dev’s branch is at the PR stage and only for quick corrections or missing knowledge so it doesn’t matter if they rebased before or honestly rebase after before the final merge.
No you just do a rebase to bring it in. Assuming you’re making atomic commits you shouldn’t have a ton of merge conflicts. If you have to do this a lot, your branch scope is really bad and the problem isn’t in how you’re using got, it’s in how you’re slicing work.
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?
You really shouldn’t apply a CC license to code. Someone who does that after saying what the dev said about not forking their open source code has no fucking clue what they’re talking about and is either about to spiral out or build something really dumb (or both).
Edit: yeah the dev seems pretty delusional
Add Istio and no one will be able to fire you without fucking up mutual TLS
Monoliths are the answer to bad microservices. Microservices are the answer to bad monoliths. It’s all cyclic and four different architects are going to have fifteen different opinions on how your system should be built. Do the thing that makes sense for your team and try to stay flexible.
Absolutes in programming tend to lead to bad designs. This is more a “I’m gonna stir up some shit on Twitter” post than real wisdom.
The same shit happened last summer when AWS came out with their “we dropped microservices for a monolith and look at our speed increase” article which ignored good design principles. Sometimes you should split things over business domains so you can deploy and code independently. Sometimes Kubernetes is the best way to handle your scale needs. The stories we normally read are about people doing it wrong (eg AWS making a bunch of microservices inside a domain sending fucking gigs of data between what should have been functions in a single service). Inexperienced folks don’t always know when to move from their minimum viable solution to something that can scale. That doesn’t mean you remove these things, it means you train on when you need them.
Should we abandon design patterns because singletons or flywheels aren’t the correct solution all of the time?
Do you have trouble in other programs with Discord running, especially resource-intensive ones? That might have been a better way for me to phrase that.
I agree with that. I think that there are people that want that deeper level. Most of your users are not going to fit into that, though. If you’re only supporting your power users, you will eventually wither and die as your power users leave.
I first bought a book with Red Hat Linux 6 or 7 in the early aughties (pre-RHEL/Fedora split). While I have actively participated in the technical improvements of project since then, I have typically stayed out of the social aspects.
I can count the number of projects where I wanted immediate feedback from random people on no hands. I do not think there are enough hands in my state to count the number of projects I’ve crawled docs and commentary from search engines. My use case for a community is an asynchronous repository of knowledge and issue tracker. Discord does none of those things.
I can’t find this being a problem. What circles do you move in where “jerk” is a problematic word?