[HN Gopher] Evaluating new software forges
       ___________________________________________________________________
        
       Evaluating new software forges
        
       Author : riidom
       Score  : 133 points
       Date   : 2023-12-17 12:26 UTC (10 hours ago)
        
 (HTM) web link (notgull.net)
 (TXT) w3m dump (notgull.net)
        
       | saurik wrote:
       | I was hoping for an evaluation of Radicle--the only forge that
       | seemed to be doing something exciting and "new", and one I
       | haven't had the time to really analyze yet--but... no such luck
       | :(.
        
         | riidom wrote:
         | Wow that looks crazy!
         | 
         | Link: https://radicle.xyz
         | 
         | But honestly, I also wouldn't write about this without a lot of
         | usage experience. For sure it's different from github/-lab etc.
         | exciting and new, as you say.
        
         | emptysongglass wrote:
         | I'm not sure you'd want any forge evaluated by this author:
         | they're extremely caustic, negative, and critical. Jaded people
         | in tech like this I just try and avoid, especially when they
         | come out against unalloyed good tech like containerization.
         | Containers are just namespaces with additions. They've allowed
         | us to narrow the gap of capability between the big three OSes,
         | even if the other two need to virtualize Linux to do so.
         | 
         | There's also nothing wrong with LLMs. How you choose to
         | integrate them into your life or forge is a choice but at the
         | end of the day they're just another tool in the toolbelt. Pick
         | what you want or need and leave the rest. I'm not forced to use
         | Copilot but I appreciate it when I need it.
        
         | k__ wrote:
         | There is also https://protocol.land and https://gitopia.com.
        
           | RealStickman_ wrote:
           | The layout of radicle.land is unfortunately pretty broken on
           | mobile.
        
             | k__ wrote:
             | Yes, it's only a month old or something. Pretty early
             | project.
        
             | BHSPitMonkey wrote:
             | What is radicle.land? Both radicle.xyz and app.radicle.xyz
             | seem fine for me on Firefox mobile. Did something change in
             | the last few hours?
        
               | k__ wrote:
               | They probably meant protocol.land.
        
           | rapnie wrote:
           | The latter is Web3/crypto la la land, and the former.. dunno,
           | got to read the code, but I would like to know about the
           | project, its goals, and who is behind it.
        
             | k__ wrote:
             | Both (and Radicle) are web3.
             | 
             | So, it's probably not your jive.
        
         | Klonoar wrote:
         | Wow! So glad someone mentioned this - I've been looking for
         | something like it, going to have to set aside time to try it
         | out.
        
         | natdempk wrote:
         | https://pierre.co/ is another interesting one, focused on a
         | product-development workflow.
        
           | idlephysicist wrote:
           | What is a Product Engineer? Is it just another name for an
           | engineer?
        
             | natdempk wrote:
             | Yeah, I don't think there is any meaningful distinction
             | there. I think Pierre is just framing things in terms of
             | solving for teams that work with product + design +
             | engineering to ship something to users that involves all of
             | those parties, whereas GitHub has primarily catered to
             | engineering.
             | 
             | Today in software companies there is basically a gap where
             | each discipline kinda prefers to work in it's own software
             | silo (eg. Asana / Figma / GitHub), but that doesn't really
             | make a lot of sense from a fundamental standpoint where all
             | of those aspects of a team want to work very closely
             | together. You end up kinda syncing a lot of info/state
             | across the silos, or via meetingss/slack etc, so I think
             | Pierre is trying to bring all that into one tool with some
             | opinionated workflow. Makes a lot of sense from my
             | perspective, curious how it ends up working out.
        
       | Klonoar wrote:
       | Would've been curious for the authors take on OneDev as well.
        
       | aulisius wrote:
       | Coincidentally, I've been mulling the same idea for a week now. A
       | self-hostable source forge + registry to serve artifacts would be
       | amazing.
       | 
       | I think the only thing you'd lose is the 'social' aspects of
       | GitHub, but I believe that can be made up with a combination of
       | rss feeds (?), ActivityPub etc.
        
         | godber wrote:
         | I think we've been thinking similarly. Decentralization will
         | have it's costs. I've been thinking Opt-In centralized search
         | for personal repos, maybe as a gitea (or other self hosted
         | options) plug-in. But as you suggest, maybe existing features
         | can be leveraged to prove the social/discoverability.
        
       | Ayesh wrote:
       | 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 as less-friction entry point to open source
       | software.
       | 
       | GitLab self hosting is also nice and flexible, but it has a more
       | "enterprise open source" feeling to it. Debian and Drupal can
       | take advantage of it, but I don't see myself hosting mini
       | projects like my mini CSS library that is also used by three
       | other strangers.
       | 
       | Source Hut is really nice too. Admittedly I don't like email
       | based workflows, so I haven't really thought about moving
       | anything there. But Source Hut has "unlisted" repos, which I
       | thought was really clever and missing from other forges.
        
         | isilofi wrote:
         | > Dependabot, and code scanning that you won't find anywhere
         | else.
         | 
         | Gitlab has equivalents you can enable as CI pipelines.
        
           | lolinder wrote:
           | So do other forges: I have Renovate [0] set up on my self-
           | hosted Forgejo and it's worked great so far.
           | 
           | [0] https://github.com/renovatebot/renovate
        
         | mst wrote:
         | Having been using gitea at work for a while as an "internal
         | mini-github" (along with a github organisation for stuff that
         | isn't purely internal or would otherwise benefit for that) I
         | have to say it ... hasn't annoyed me noticeably.
         | 
         | So I think I'd put gitea* on that list as well.
         | 
         | (I don't think I disagree with your opinions about the ones you
         | -have- listed)
         | 
         | * and I mean that to include forgejo, I think, though I haven't
         | tried it so YMMV
        
         | meibo wrote:
         | > 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.
        
           | paradox460 wrote:
           | 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
        
             | aleph_minus_one wrote:
             | > 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.
        
               | Kwpolska wrote:
               | Git is decentralized. Ticketing systems and mailing lists
               | as found on SourceHut and many other forges aren't.
               | 
               | And if SourceHut disappears, what would you do with the
               | repository? You'd upload it to a new forge, but how would
               | you tell users where to find it, how would the users know
               | this is the original source and not a hostile fork? It's
               | better to pick a stable, trustworthy. and 21st-century
               | place like GitHub or GitLab instead of SourceHut.
        
               | aleph_minus_one wrote:
               | > It's better to pick a stable, trustworthy. and 21st-
               | century place like GitHub or GitLab instead of SourceHut.
               | 
               | It's better to not make yourself (much) dependent on
               | functionalities that only the respective software forge
               | provides.
        
               | Kwpolska wrote:
               | What would you suggest instead? How would you replace
               | pull requests, or even sending patches via email to
               | mailing lists?
        
               | potatopatch wrote:
               | I'd don't really see a difference between sending an
               | email to a list or to a maintainer. Maybe that's an
               | argument for not adding and adapting to unnecessary
               | concepts like a web based pull request.
        
               | Kwpolska wrote:
               | What if there's more than one maintainer? How do you
               | build any sort of community without a place for
               | discussion?
        
           | aleph_minus_one wrote:
           | > > 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. :-)
        
             | johnny22 wrote:
             | 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.
        
             | plagiarist wrote:
             | Are the hipsters the ones using email or refusing to use
             | email? I could see a dude rolling up on a penny farthing to
             | explain why email is the one true workflow. But he'll be
             | embarrassed when a more powerful hipster shows up using a
             | telegraph to send diffs by wire.
        
         | ForkMeOnTinder wrote:
         | I'm curious what you thought was missing from Codeberg.
        
         | matheusmoreira wrote:
         | GitHub Sponsors is pretty great. Seems like a perfectly ethical
         | way for open source developers to earn money. Doesn't depend on
         | copyright, artificial scarcity, advertising. I really like it.
        
       | dboreham wrote:
       | Quick note that Gitea has its own CI (roughly Github Actions
       | compatible) so you don't need to use Drone.
        
       | sebastianconcpt wrote:
       | Is not hard for me to see a case being built around the idea of
       | finding value in having code to stay excluded from the surface
       | exposed to AI so it becomes impossible for it to predate it.
       | 
       | It's a type of "security" that doesn't find an answer in "better
       | AIs" or "AIs with improved alignment". The value comes out of
       | being safe from the risk that can come out of the humans in
       | control of these AIs.
       | 
       | I comes out of staying away and making impossible for any and all
       | AIs to touch it.
       | 
       | Like the difference between food from a chef and
       | hyperindustrialized food.
       | 
       | What if you want chef food only?
       | 
       | In the same way, exclusively human software creations.
        
         | Jgrubb wrote:
         | I like this analogy but I guess I see it more like man
         | inventing the knife, so he doesn't have to rip the animal to
         | shreds with his bare hands anymore.
        
           | sebastianconcpt wrote:
           | Except the knives do not have the capacity to give parts of
           | the protein to other knives users surreptitiously and it's in
           | AI's very nature to absolutely do that.
        
         | steezeburger wrote:
         | Does the chef not use tools?
        
           | sebastianconcpt wrote:
           | Robot chefs are tools? Are they chefs?
        
         | ahepp wrote:
         | Shall we call it the "slow code movement"?
        
       | btreecat wrote:
       | I think it's time we collectively mature past the point where
       | taking unsubstantiated pot-shots at tools we don't "love" is seen
       | as a value add to commentary.
       | 
       | In this case calling k8s a "nightmare" is a strong red flag akin
       | to the mantra of "java is slow". It lacks the nuance of hands on
       | XP and reeks of rules of thumb miss applied to the point of
       | catchphrases.
        
         | steezeburger wrote:
         | Sad to see this down voted. I agree. They also sound
         | insufferable. Maybe it's just their writing style, trying to be
         | inflammatory for engagement, but they are not someone I would
         | want to work with.
        
           | tailspin2019 wrote:
           | You and the parent seem to dislike the author sharing their
           | _opinions_ on things on _their own blog_. And yet you 're
           | happy to share your own dismissive opinions on the author
           | here.
           | 
           | FWIW I find the author's _obviously subjective_ opinions on
           | their tools much more valuable than your _obviously
           | subjective_ opinions of this author.
        
             | meepmorp wrote:
             | > You and the parent seem to dislike the author sharing
             | their opinions on things on their own blog
             | 
             | At least w.r.t. the original comment, this seems like a
             | misunderstanding. GP was saying that, absent any
             | explanation for why the author came to the opinions they
             | did, the article doesn't say much of value. They don't
             | dislike the author sharing their opinions on the author's
             | own blog.
        
             | steezeburger wrote:
             | I don't care if the author shares their opinions, but I'm
             | free to share mine as well, and I agreed with the parent
             | comment at the time it was downvoted.
             | 
             | I've just been noticing a trend of people, like the article
             | author, who are quick to dismiss things for reasons that
             | are inconsistent and dogmatic. Why be so close minded? I
             | think it's okay to be dismissive of the dismissive. Which,
             | I didn't really dismiss him did I? I read his entire
             | article.
        
             | Klonoar wrote:
             | 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 discussions where reviews like these often
             | come from people just tinkering and looking for the next
             | thing to mindlessly experiment with. It's not always
             | representative of real world trade offs.
             | 
             | (I say all this as someone who self hosts a Gitea instance)
        
               | morelisp wrote:
               | 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.
        
               | emptysongglass wrote:
               | 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.
        
       | bachmeier wrote:
       | If your goal is to put some code out there just to share it with
       | others, any of those will work. There's also Bitbucket,
       | Sourceforge, and self-hosted Fossil. The blog author seems to be
       | looking for more of an "enterprise" open source option. You could
       | even use Gitolite or GitWeb if you're willing to self-host.
        
         | jzb wrote:
         | Nothing says "unmaintained," or inertia, quite still like
         | having a project hosted on Sourceforge. I'm sure there's a few
         | exceptions that are thriving on Sourceforge, but... it's kind
         | of a relic at this point. It'd be cool if it could have a
         | revival, but I think they've tried that a few times and never
         | quite got there. I certainly wouldn't put anything new there,
         | myself.
        
       | jmclnx wrote:
       | I just went back to kind of "anonymous ftp" via my gemini site on
       | sdf.org. I find it far easier to maintain. When I make a change,
       | a script packages up the change and sends it to sdf.
       | 
       | My github repositories were changed to point to it. The latest
       | change by Microsoft made me move, I was considering a move when
       | Copilot became a thing. 2FA got me off my butt to finally move.
        
         | jckahn wrote:
         | What about requiring 2FA made you leave?
        
           | jjgreen wrote:
           | Microsoft barking orders at you?
        
           | jmclnx wrote:
           | In my case I had to give them my cell phone, I have multiple
           | platforms and no one M/S recommended solution would not work
           | for all. I would not give MS my cell.
        
       | toastal wrote:
       | I've been moving into a self-hosted direction for a lot of my
       | stuff as a lot of it really wasn't being used by anyone but
       | myself anyhow. My latest two projects are darcs on my home server
       | using just SSH+Nginx for HTTP with an apply hook that run `nix
       | flake check` & on the server end, a hook that runs `nix build`
       | which not only checks the build, but also has the derivation in
       | Nix store for me to pick up later as that server doubles as a
       | substitutor. Collaboration can still be done via email of patches
       | or DMing a pull request from someone else's remote repo. It's
       | crazy how much we've been defaulting to tools that are so
       | complicated--especially ones that require accounts to participate
       | & have a social media features tacked on everywhere to cause the
       | sorts of social media anxiety it does everywhere else. When the
       | amount of collaborators is low, self-hosting is hardly a barrier
       | that needs extra scaling.
       | 
       | Weird the author said email was a pain, but last patch I received
       | it was as easy as `himalaya read --raw X | git am` to apply &
       | pointing out that modern email clients do a bad job supporting
       | this seems more damning of those clients than the workflow.
        
         | misterio7 wrote:
         | You might want to try out self hosting hydra! It's pretty sweet
         | for your usecase (building and caching Nix stuff, in a smart
         | way). It can even run arbitrary commands (e.g. moving a release
         | branch)
         | 
         | EDIT: here's how I do it, in case it's useful:
         | https://github.com/Misterio77/nix-config/blob/a74b2ede/hosts...
        
       | __float wrote:
       | > 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
        
         | ihattendorf wrote:
         | But is it a _complicated_ YAML file?
        
           | eviks wrote:
           | it's also not "just cloning Git repos and running commands"
        
           | rco8786 wrote:
           | They never start that way, do they?
        
           | IshKebab wrote:
           | 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's pretty
           | widely known that you should keep as much stuff out of the
           | YAML as possible, so you can run CI locally.
           | 
           | That was definitely the most bullshit criticism in the
           | article. Clearly not even something they actually care about
           | because they settled on Drone CI which is configured in
           | exactly the same way.
        
             | ahepp wrote:
             | > 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 transition my CI away from Jenkins (which was always
             | pretty rough, but I knew I could keep the builds running
             | locally that way).
             | 
             | I guess the real proof will be if I'm able to ever leave
             | GitHub, but I feel pretty good about the amount of lock-in
             | vs the benefits of the service.
        
               | tuukkah wrote:
               | > _to run CI in a container specified by the repo_
               | 
               | Would you happen to have an example YAML at hand?
        
               | ahepp wrote:
               | Here's one:
               | 
               | https://github.com/ahepp/resume/blob/d7778b1339271cbd7812
               | 634...
               | 
               | 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/a144ee06b868ae867b
               | 287...
               | 
               | 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.
        
               | tuukkah wrote:
               | Thank you for sharing! This shows nicely how you can keep
               | the GitHub YAML at minimum by referring to an action (in
               | this case devcontainers/ci) which configures itself based
               | on the content of the repo.
        
           | flohofwoe wrote:
           | On other CI systems it is also a good idea to only use the
           | YAML file to call a bash/python/deno/... script which does
           | the actual work.
        
       | LoganDark wrote:
       | I also checked out SourceHut, but they're unfortunately not
       | compatible with my email provider, and after some discussion with
       | Drew (the founder) it started to sound like I'm not welcome
       | unless I bring a real legal name and human identity. I understand
       | how that type of collaboration can be valued and desired, but it
       | excludes me, so I didn't pursue SourceHut any further. Something
       | to think about if you ever consider it - no pseudonyms, no custom
       | emails, use your real name and personal email address, or you'll
       | be actively rejected by their software.
        
         | emersion wrote:
         | SourceHut staff here. We don't have any requirement for "real
         | legal" names or anything -- and in fact I find these
         | requirements very harmful in general (glad we finally got rid
         | of them in the kernel). I know multiple people collaborating on
         | SourceHut with a pseudonym and this causes no issue at all.
         | SourceHut does assume a stable email address but that's about
         | it.
         | 
         | That's my own take -- for Drew's see
         | https://drewdevault.com/2023/10/31/On-real-names.html
        
           | LoganDark wrote:
           | It's not a requirement, but I heavily got the vibe that
           | pseudonyms are not welcome. To quote Drew, "You should be
           | using your real email address with the mailing lists, so that
           | people can reach you and treat you as a human being, not as a
           | proxy of one."
           | 
           | I'm just not comfortable putting myself out there like that.
           | I get it's not technically against the rules to do it
           | differently, but it's just... frowned upon.
           | 
           | Other justifications included that my peers would be sharing
           | their real names and personal email addresses, so I'm being
           | non-courteous by not doing the same... I dunno. It wasn't a
           | particularly productive email chain, but it told me all I
           | needed to know.
        
             | morelisp wrote:
             | 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?
        
               | LoganDark wrote:
               | 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".
        
               | aleph_minus_one wrote:
               | > 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.
        
       | RealStickman_ wrote:
       | 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.
        
         | steezeburger wrote:
         | The whole article feels really inconsistent on what the author
         | likes and dislikes and his reasonings behind such things.
         | Really off putting article imo.
        
         | pacbard wrote:
         | If drone's open core is a problem, there is always woodpecker,
         | which was forked from the original drone before they changed
         | their license a few years ago.
        
         | thih9 wrote:
         | Open core was one of the reasons. Another was that it's also
         | "AI-powered".
        
         | revskill wrote:
         | If the reasoning is "gitlab is bloated" then it's more
         | reasonable to me.
        
         | xondono wrote:
         | 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 the end I switched to Gitea as well and I've been happy with
         | it for years at this point.
        
           | tandav wrote:
           | I found it difficult to find documentation on how to run
           | gitlab in docker without nginx (I use caddy for reverse
           | proxy) and enable the registry. For anyone having the same
           | problem, here's a working Dockerfile.
           | https://gitlab.tandav.me/tandav/notes/-/issues/5516
           | 
           | I've tried github actions, drone, woodpecker and gitlab. In
           | my opinion gitlab has a much more flexible CI system.
        
             | cevn wrote:
             | I was searching everywhere for this 3 months ago, then
             | switched to forgejo lol. Good tip though.
        
           | emptysongglass wrote:
           | I've been running the GitLab Omnibus for 4 years now. Easiest
           | upgrades ever. Never once had a bad update that required
           | manual workarounds.
        
             | Xiol32 wrote:
             | We run a self-hosted Gitlab Premium instance installed with
             | Omnibus for 30 devs and we actually install Gitlab updates
             | on a cron.
             | 
             | Had two upgrades that needed minor manual intervention in 5
             | years. Uptime better than Github despite the #yolo
             | approach.
        
       | eviks wrote:
       | > the email-based workflow was a lot clunkier than I expected
       | 
       | > If you want to create a repo for PR's sake, email me at dev at
       | notgull dot net and I can set you up.
       | 
       | So is there no way to allow seamless forking like on GitHub
       | without high risks of abuse?
        
       | huijzer wrote:
       | You can nowadays use the built-in CI instead of Drone. It's
       | experimental but has worked fine for me so far.
        
       | confd wrote:
       | It's a wonder how much freedom can be gained by eschewing the
       | desire to be discovered.
        
         | thih9 wrote:
         | The author didn't eschew discovery - the article mentions
         | mirroring to github to take advantage of their code discovery.
        
           | confd wrote:
           | And what do you think of that?
        
             | thih9 wrote:
             | 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.
        
       | thih9 wrote:
       | Given the rise of "AI-powered" forges, i.e. platforms that add
       | the source of projects hosted there to their AI models, is it ok
       | to upload GPL-licensed code there?
        
       | IshKebab wrote:
       | This seems pretty filled with arbitrary back-reasoning for
       | decisions they've already made based on guy feelings.
       | 
       | They don't like "AI-powered" because it is a vague, ill-defined
       | term... except it's extremely obvious and well defined what
       | GitHub means by that (and they've even used copilot and liked
       | it!)
       | 
       | Gitlab CI is rejected because it uses YAML for config... like
       | every other CI system they mention.
       | 
       | Gitlab isn't ok because it's open core, but Drone CI is.
       | 
       | Could have been an interesting comparison but it wasn't.
        
       | dartos wrote:
       | Onedev is pretty good. I run it locally and it's been grwat
        
         | jamesu wrote:
         | Onedev has pretty good features built-in. They even seem to
         | have a paid option now too which adds some additional features,
         | though I wonder what the division between paid and unpaid
         | features will look like as the project ages. To be fair though,
         | there only seems to be one person consistently working on it.
         | 
         | Also there is just something about its sidebar-centric UI I
         | just don't like. It's not as bad as gitlab but still, it bugs
         | me every time I use it.
        
       | sebastianconcpt wrote:
       | Is Microsoft secretly learning from the secrets in private GitHub
       | repositories?
        
         | bionhoward wrote:
         | No, but Microsoft has an AI term of service which forbids use
         | of Microsoft AI for AI development.
         | 
         | """ AI Services q. AI Services. "AI services" are services that
         | are labeled or described by Microsoft as including, using,
         | powered by, or being an Artificial Intelligence ("AI") system.
         | 
         | iii. Limits on use of data from the AI Services. You may not
         | use the AI services, or data from the AI services, to create,
         | train, or improve (directly or indirectly) any other AI
         | service.
         | 
         | """
         | 
         | If you ask GitHub Copilot Chat about the issue, it/they suggest
         | seeking professional legal advice. To use GitHub Copilot. An AI
         | trained on our AI code from GitHub. To write AI code. For
         | paying customers.
         | 
         | https://drive.google.com/file/d/1DIj6-mgyxVRBJNEeVZMV8t8ec2L...
         | 
         | Satya Nadella is King Midas. I emailed him and their legal team
         | about it many times and he could have personally gone into the
         | codebase and deleted this service term by now. I reported them
         | to the State of Washington Attorney General (you can, too), and
         | to the Federal Trade Commission Antitrust Team (you can, too),
         | and to the Department of Justice Antitrust Enforcement Division
         | (you can, too). Unclear how to report this to the EU Parliament
         | AI Act folks, but maybe they posted new info since I last
         | checked.
         | 
         | It's a single line of text, certainly unfair and unreasonable
         | and almost surely illegal in pretty much every relevant
         | jurisdiction, so there's certainly no an argument to be made
         | that the fix is too technically challenging, even in light of
         | Microsoft's historical ineptitude.
         | 
         | We could check to see if Washington State has laws against
         | contractual restraint of trade like California does. (Hint,
         | Hint.)
        
       | sneak wrote:
       | He doesn't want to use GitHub because it trains Copilot on f/oss
       | code, but then selfhosts and mirrors all his code to GitHub
       | anyway?
       | 
       | Why release free software if you don't want others to use it?
       | 
       | Why provide any code to GitHub if you don't want GitHub to use
       | it?
       | 
       | This is just tribalism, the ideology isn't even consistent.
        
       | godber wrote:
       | I've kind of anticipated this sentiment and have been thinking
       | about providing Gitea hosting. Though I've been a little
       | discouraged by Gitea's release of their own cloud hosting
       | service.
       | 
       | This blog post and the revenue growth at Gitlab over the last two
       | quarters appear to be evidence of people wanting to moving away
       | from GitHub (though their earnings report attribute the growth to
       | other initiatives, clearly I had no real insight on this). As an
       | extension of my self hosting of Mastodon efforts from last year I
       | rolled up my other minor hosting efforts into https://hawt.cloud
       | as a place to experiment with providing services like this.
       | 
       | This all ties in with the "Open Web" or "Small Web" sentiments
       | I've seen expressed recently. The hyperscalers are locking more
       | and more up into their ecosystems but there should still exist
       | small vendors/hosting/service providers. They'll never scale or
       | be as reliable as the big guys but if they cease to exist a lot
       | will be lost.
        
       | bob1029 wrote:
       | > I hope they haven't started down the slow and painful process
       | of enshittification by following vague, ill-defined industry
       | trends!
       | 
       | Has anyone else found themselves wondering if GitHub switched to
       | a different web framework?
       | 
       | I feel like they moved further down the client-side rendering
       | rabbit hole recently. Their UI feels increasingly janky to me.
       | Several times a day I get a view of completely un-styled HTML
       | that eventually organizes itself into the appropriate
       | presentation.
       | 
       | For many scenarios, the GH web UI used to be preferable over
       | navigating through visual studio because of how responsive it
       | was. Now, I find the exact opposite to be true. I avoid the GH
       | web UI as much as possible. VS2022 isn't great, but at least it's
       | not implemented using react on top of some bullshit chrome
       | wrapper.
        
         | mwcampbell wrote:
         | Yeah, it's React. It's been a pretty frequent topic of
         | discussion in some corners of the fediverse lately, e.g.
         | https://mastodon.social/@bendelarre/111585575314778379
        
           | bob1029 wrote:
           | Thank you for the link. I've been trying to find any
           | discussion whatsoever. This commentary inspired me to submit
           | a support issue.
           | 
           | I intend to start some drama with GH over this. ReactJS
           | _will_ win if we do nothing.
        
             | mwcampbell wrote:
             | Here's another, older thread, including some inside
             | perspective:
             | https://toot.cafe/@slightlyoff/111390409414137820
        
       | lucideer wrote:
       | This post bothered me.
       | 
       | Perhaps I'm being too nitpicky, and there's nothing inherently
       | wrong with their final choices, but their criticisms of the other
       | systems alongside their reasons for choosing what they did are
       | contradictory; overall the article was internally inconsistent.
       | 
       | Gitlab was dismissed for the SaaS being only open-core, despite
       | opting for self-hosting in the end. Codeberg was dismissed for
       | having limited CI, but in the end they went for a separate
       | standalone CI anyway (& almost the same platform as Codeberg,
       | just with the added overhead of self-hosting).
        
         | philipov wrote:
         | Open-core was mentioned, but was not a dealbreaker. Gitlab was
         | dismissed for just following along with what GitHub does and
         | being "AI-powered"
        
           | Tadpole9181 wrote:
           | No, the parent is right. The very first two reasons given
           | were being open-field and that they "didn't wasn't to be a
           | sysadmin".
        
         | dabedee wrote:
         | Yes, they dismissed Gitlab in part because of the self-hosted
         | argument: "I know I can download GitLab and set it up on my own
         | server. However, I'm a software developer, not a sysadmin. I
         | want to spend my time developing software, not putting out
         | fires and paying AWS bills for the rest of time."
         | 
         | Yet they ended up choosing a self-hosted option, Gitea, because
         | it was recommended by an acquaintance and they set up a couple
         | lightsail servers on AWS to run it.
         | 
         | It's totally fine for the author to share their preferences;
         | they're just exhibiting the internal inconsistencies and
         | irrational behavior we're probably all guilty of at one point
         | or another.
        
         | mardifoufs wrote:
         | To be honest gitlab can be a very painful beast to maintain if
         | you just want to use it for yourself, especially if it's
         | exposed to the public internet. The update rate is a bit
         | insane, and while the updates are usually easy you still end up
         | having to update almost every week or so, and I think monthly
         | for critical security updates.
        
       | lloeki wrote:
       | I really wish a cross site standard emerged to enable PRs from
       | one forge to the next without creating accounts:
       | 
       | - clone repo from original forge, push on yours
       | 
       | - open PR on your forge, kicking in a like-blog-trackbacks-of-
       | yore API so that the PR would be known/opened on the original
       | forge.
       | 
       | The thing would really put the "Pull Request" back in PR.
       | 
       | Lots of things to define and handle correctly to prevent abuse
       | but it could be a much better distributed experience.
       | 
       | I guess big players like GitHub would nit like that too much
       | though as it would fragment their coding social network.
        
         | erlend_sh wrote:
         | That's what ActivityPub in GitLab and elsewhere aims to enable:
         | https://gitlab.com/groups/gitlab-org/-/epics/11247
        
       | nirga wrote:
       | It's hard to build a community around an open source if you're
       | not on GitHub imo. And if you're not building an open source,
       | than iiuc GitHub can't use your code for copilot training so the
       | main reason for not choosing GitHub according to the post isn't
       | relevant.
        
       | rapnie wrote:
       | https://ayllu-forge.org/
       | 
       | > Hyper Performant & Hackable Code Forge Built on Open Standards.
       | Ayllu is a lightweight code forge designed to enable individuals
       | and community projects to develop software in collaboration
       | across open internet standards.
        
       | tshirttime wrote:
       | There's gitawonk.com, a gitea instance that lets you charge
       | people for your commit history.
        
       | easterncalculus wrote:
       | 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 will ban is.
       | 
       | What is the point of a free software forge if you can't host
       | certain types of (legal) projects? It's hard to take a platform
       | seriously, to move all of your work there when the administrators
       | can (and most importantly, actually do) ban your projects based
       | solely on their personal views.
       | 
       | [0]: https://sourcehut.org/blog/2022-10-31-tos-update-
       | cryptocurre...
        
         | apitman wrote:
         | 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.
        
         | rodlette wrote:
         | +1. I moved from Sourcehut when it announced IRS change of TOS.
         | I realised I would prefer to support less discriminatory
         | forges.
         | 
         | I also have no interest in crytocurrency.
        
       | apitman wrote:
       | > Let me be clear, GitHub is still far and away the best website
       | for open source discover
       | 
       | We need to separate discovery from hosting across the web. It's
       | convenient to implement them together, but certainly not
       | necessary. Bring back the link aggregators!
        
       | jauntywundrkind wrote:
       | This is one of the first times I've seen someone who has casual
       | access to Kubernetes.
       | 
       | They spent a lot of the post saying how they didn't really want
       | to run stuff,
       | 
       | > _However, I'm a software developer, not a sysadmin. I want to
       | spend my time developing software, not putting out fires and
       | paying AWS bills for the rest of time._
       | 
       | But then their friend convinced them to "kubectl apply" a couple
       | of manifests & they got a bunch of stuff spin up quickly, on what
       | should be a reliable-ish maintained-by-other-people cluster. This
       | is the first time I've seen a win like this & it feels like such
       | a sweet spot!
        
       | flohofwoe wrote:
       | The author is too quick to dismiss Gitlab IMHO. I use Gitlab on
       | the job, and Github for my hobby stuff, and Gitlab feels in many
       | ways like a Github for professional use. The Gitlab CI system
       | alone is a difference like night and day compared to GH Actions.
        
       ___________________________________________________________________
       (page generated 2023-12-17 23:01 UTC)