Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Evaluating new software forges

notgull.net

Post reply on HN
Print view View original

91–100 of 138 posts

Re: Evaluating new software forges

#91

Post by aleph_minus_one »

meibo wrote: post #43
Ayesh wrote: post #5

Having tried GitHub, GitLab, Source Hut, Codeberg, and BitBucket (RIP), I think the only serious options are GitHub, GitLab self hosted, and Source Hut. GitHub owned by MSFT aside, and also putting their AI push _also_ aside, GitHub has things like Sponsors, Dependabot, and code scanning that you won't find anywhere else. They sure are luring you into ecosystems that require a huge escape velocity, but GitHub serves…

> and Source Hut Not a very serious option if you're looking for anyone from the 21st century to contribute to your project. No, the email workflow doesn't get better by just screaming "it's not that bad!" over and over again. I'm looking forward to the federation work that is being done for forgejo, that will be big if it works out as it seems like it will.

> > and Source Hut

> Not a very serious option if you're looking for anyone from the 21st century to contribute to your project. No, the email workflow doesn't get better by just screaming "it's not that bad!" over and over again.

Perhaps the maintainers of the respective project consider filtering out contributions from "hipster programmers" actually desirable for the project. :-)

Re: Evaluating new software forges

#92

Post by aleph_minus_one »

paradox460 wrote: post #88
meibo wrote: post #43

Earlier quoted context omitted.

> and Source Hut Not a very serious option if you're looking for anyone from the 21st century to contribute to your project. No, the email workflow doesn't get better by just screaming "it's not that bad!" over and over again. I'm looking forward to the federation work that is being done for forgejo, that will be big if it works out as it seems like it will.

Also, the founder has an unfortunate history of just up and abandoning his projects when they stop being fun for him. I used his media host/imgur alternative in the past, and it spontaneously just disappeared one day. I'd rather that not happen to my source code

> I used his media host/imgur alternative in the past, and it spontaneously just disappeared one day. I'd rather that not happen to my source code

Git is decentralized.

Re: Evaluating new software forges

#93

Post by apitman »

easterncalculus wrote: post #85

One of the things that people should know about SourceHut is that even though it is "Free Software", it is not a very "free" platform. Certain types of projects are a red line to the owner and will be removed[0]. I'll be honest, I do not trust cryptocurrency stuff and don't believe that it has utility. I hold none, I don't use it. That being said, this makes me wonder what the next category of projects that SourceHut…

This comes up over and over on different platforms. It's sad to me how many services that are built on open source software don't allow you to use a custom domain. It's not that hard. Let's Encrypt makes it almost trivial.

Re: Evaluating new software forges

#94

Post by [deleted] »

__float wrote: post #15

> Rather than needing a complicated YAML file to run a CI system, it’s just cloning Git repos and running commands. How do you define what repos you need and which commands are run? Ah, it is indeed also a YAML file: https://srht.site/automating-deployments

[deleted]

Re: Evaluating new software forges

#95

Post by emptysongglass »

xondono wrote: post #53
RealStickman_ wrote: post #21

I'm surprised the author rejected using GitLab because of its Open Core model, but decided foe using Drone CI, which appears to be following a similar model.

What I understood is that the author is not happy about the “Open Core” model and would prefer truly OSS, but the real deal breaker is maintaining Gitlab. My experience self hosting Gitlab was pretty terrible, it requires a lot of attention on your part, and internally the project feels like a bunch of fragile scripts. There’s also little documentation for when things go wrong, with was almost every single update. In…

I've been running the GitLab Omnibus for 4 years now. Easiest upgrades ever. Never once had a bad update that required manual workarounds.

Re: Evaluating new software forges

#96

Post by aleph_minus_one »

LoganDark wrote: post #81
morelisp wrote: post #73

Earlier quoted context omitted.

Pseudonyms are fine, hapaxnyms are what's cautioned against. Given that you use "Logan Dark" in several places surely you recognize why this is useful?

What is a "hapaxnym"? I can't find a definition or even any results for this word online. And it's not "Logan Dark", it's "LoganDark".

> What is a "hapaxnym"? I can't find a definition or even any results for this word online.

A portmanteau word of "hapax legomenon" (https://en.wikipedia.org/wiki/Hapax_legomenon) and "pseudonym", i.e. a pseudonym that is used nowhere else.

Re: Evaluating new software forges

#97

Post by ahepp »

tuukkah wrote: post #87
ahepp wrote: post #58

Earlier quoted context omitted.

> You don't have to make Gitlab/GitHub YAML files complicated if you don't want to. The "script" section can be just a call to a normal shell/Python/Typescript CI script. It took me an embarrassingly long time to learn that you don't need to use their little action plugins for everything. Once I figured that out, and figured out how to run CI in a container specified by the repo, I was actually quite happy to transit…

> to run CI in a container specified by the repo Would you happen to have an example YAML at hand?

Here's one:

https://github.com/ahepp/resume/blob/d7778b1339271cbd7812634...

It uses GitHub's devcontainer plugin. There's a devcontainer config at .devcontainer/devcontainer.json, which says to use the image specified by .ci/Dockerfile.

So when I'm developing on any Linux system, I can run

    $ docker build .ci/Dockerfile -t my-container
    $ docker run --rm -it -v $(pwd):/project -w /project my-container
And have a shell with my LaTeX environment all ready to go.

I can also create a GitHub codespace from the devcontainer config. I'm excited to explore more of the possibilities with devcontainers. I've included Dockerfiles with all my projects for quite a while now, it's cool to have some kind of standard written down that tooling can be written for.

I think the GitHub YAML a slight improvement over the old Jenkins configs it replaced:

https://github.com/ahepp/resume/commit/a144ee06b868ae867b287...

For one, there's no out-of-band Jenkins UI I need to configure the pipeline in. The syntax is probably a slight improvement over Jenkins. I'm also happy to use opaque plugins for certain things, like uploading to S3.

Re: Evaluating new software forges

#98

Post by emptysongglass »

morelisp wrote: post #72
Klonoar wrote: post #63

Earlier quoted context omitted.

They’re not saying that the author can’t post whatever they want on their blog. They’re saying that we, as a community, should not elevate unsubstantiated writing that comes across as “I don’t truly understand these things or have deep experience, but this is what everyone else says on every other blog post or comment, and I’m parroting it”. I would add on to it that I feel there’s sometimes a real thing in these dis…

I have (with a team) built a couple on-prem Kubernetes clusters that handle billions of requests per day, as well as written Kubernetes controllers and operators. Kubernetes is a nightmare, and I'm glad that some people are not afraid to point out the state of the emperor's outfit.

I disagree and think it's time we all moved on from kneejerk hating anything either a. new or b. misunderstood. That includes things like AI, containers and Kubernetes.

Kubernetes started in a rough shape but it has been chiseled over the years to be boring tech that just works and provides a layer of abstraction to build abstractions on top of.

I've been working with Kubernetes for the past 6 years. It's fine. It does its job. Let's all move on from the outrage.

Re: Evaluating new software forges

#99

Post by johnny22 »

aleph_minus_one wrote: post #91
meibo wrote: post #43

Earlier quoted context omitted.

> and Source Hut Not a very serious option if you're looking for anyone from the 21st century to contribute to your project. No, the email workflow doesn't get better by just screaming "it's not that bad!" over and over again. I'm looking forward to the federation work that is being done for forgejo, that will be big if it works out as it seems like it will.

> > and Source Hut > Not a very serious option if you're looking for anyone from the 21st century to contribute to your project. No, the email workflow doesn't get better by just screaming "it's not that bad!" over and over again. Perhaps the maintainers of the respective project consider filtering out contributions from "hipster programmers" actually desirable for the project. :-)

Can't say i feel much like a hipster programmer after doing some amount of programming for 20 years. I still prefer the github approach.

Re: Evaluating new software forges

#100

Post by thih9 »

confd wrote: post #45
thih9 wrote: post #38

Earlier quoted context omitted.

The author didn’t eschew discovery - the article mentions mirroring to github to take advantage of their code discovery.

And what do you think of that?

At first I thought it was pointless, i.e. to migrate from github only to mirror your code there eventually.

But in the end I like it — mirroring self hosted source forges to github seems a good way to raise awareness of github alternatives.

Post reply on HN