The docker quickstart asks me to mount the docker socket, an incredibly dangerous act that fundamentally breaks the isolation that containers are supposed to provide. I see no attempt to explain why this level of access is necessary.
I can guess why you think you need it, but whatever the reason it's not good enough. If you need job workers or some other kind of container, tell me how to run those with docker compose.
This looks super cool - especially given the changes to github’s leadership.
One minor note - on mobile safari there didn’t seem to be any state update on press of buttons, and submission was not clear until the backend server seemed to respond. My internet connection is a little slow and it was unclear tapping the button worked. I would expect a little loading state or at least ui to show the button as disabled during submission.
Code discussion anywhere anytime
Select any code or diff to start discussion. Suggest and apply changes. Discussions stay with code to help code understanding.
How do the discussions stay with the code? Git notes?
From their docs, apparently it just modifies the source code, although their LOC didn't change when they hit save in their video demo, so I'm not sure.
I recall looking at it maybe 2-3 years ago and deciding against it. And it never seemed to get traction in the selfhosted community either.
...but I can't for the life of me recall why. Definitely wasn't a radioactive red flag issue...but some aspect around CI wasn't for me.
In general though with things like this that carry an open license and have a docker image you're better off trying it yourself than listening to randoms like me
For me the bus factor was a bit of a red flag, plus I prefer the layout in forgejo/gitea. Also didn't like that there wasn't really any obvious way to link in an external CI, and of course it's written in java so had that to factor in too.
This is why I dropped it. The CI/CD configurations were some weird proprietary format where as gitlab/gitea/forejo are all (mostly) feature compliant with my already existing github workflow files
I evaluated moving from Gitea to OneDev before Gitea had CI. OneDev was useable, I didn't mind it, but I don't run java anywhere else so I decided against adopting it. A few years later and now Gitea/Forgejo are at feature parity.
Fossil started as "not invented here", but it has grown into something I like a lot more than Git. Knowing how to use a version control system should be an incidental skill (akin to simple shell commands like "cp" and "ln"), not something that needs to be mentioned in a job posting's role description.
I also appreciate that the default workflow for undoing bad merges is a whiteout rather than a true "delete".
To each his own, but having worked with CVS, SVN, Perforce, Git, and Fossil, the centralized model is much less work for release engineering and administration most of the time. If I were a maintainer of the Linux kernel of one of the many Linux distros where you have potentially thousands of contributors to one codebase, I would use git because it scales up better.
However, I wouldn't underestimate the value of scaling down well, especially for all the people around here building some startup out of a barndominium. A VCS that includes its own GUI-based admin tool and is simple enough to used by some high school intro to web design class is a good thing in my book.
I was turned off by the necessity of using users and permissions; it feels unnecessary for local development and kind of a PITA if you have many repos.
It works exactly as advertised though; my gripes aren't technical.
A better question is why does it take any time to maintain a tool like this? I spend zero time maintaining my open-source browser (Firefox). It just periodically updates itself and everything just works. I maybe spend a bit of time maintaining my IDE by updating settings and installing plugins for it, but nothing onerous.
A tool like this is not fundamentally more complex than a browser or a full-fledged IDE.
Our gitea instance had roughly five minutes of downtime in total over the past year, just to upgrade gitea itself. All in the middle of the night. How much downtime has GitHub seen over the same period, and how many people's work was affected by that?
I've been hosting a git service for quite a while now and it's maybe around half an hour per year of maintenance work. It's totally worth it in my opinion, it's so much better on almost every way ... One big reason is decentralization. Full control of data, change what you want, then things like the current npmjs attack show the downsides of having everyone using the same thing, and so much more
One answer might be to avoid LLMs training off the intellectual property that your humans typed out for you. But as LLM code generation tools take off, it's a losing battle for most orgs to prevent staff from using LLMs to generate the code in the first place, so this particular advantage is being subverted.
Especially as self-hosting means loosing the community aspect of GitHub. Every potential contributor already has an account. Every new team member already knows how to use it.
You’re assuming people are self-hosting open source projects on their gut servers. That’s often not the case. Even if it were, GitHub irked a lot of people using their code to train Copilot.
I self-host gitea. It took maybe 5 minutes to set up on TrueNAS and even that was only because I wanted to set up different datasets so I could snapshot independently. I love it. I have privacy. Integrating into a backup strategy is quite easy —- it goes along with the rest of my off-site NAS backup without me needing to retain local clones on my desktop. And my CI runners are substantially faster than what I get through GitHub Actions.
The complexity and maintenance burden of self-hosting is way overblown. The benefits are often understated and the deficiencies of whatever hosted service left unaddressed.
When I publish open source code, I don't mind if people or companies use it, or maybe even learn from it. What I don't like is feeding it into a giant plagiarism machine that is perpetuating the centralization of power on the internet.
because:
1) privacy - don't want projects leaving a closed circle of people
2) compliance - you have to self-host and gitlab/github are way too expensive for what they provide when open-source alternatives exist
3) you just want to say fuck you to coorperate (nothing is free) and join the clippy movement.
The docker quickstart asks me to mount the docker socket, an incredibly dangerous act that fundamentally breaks the isolation that containers are supposed to provide. I see no attempt to explain why this level of access is necessary.
I can guess why you think you need it, but whatever the reason it's not good enough. If you need job workers or some other kind of container, tell me how to run those with docker compose.
This looks super cool - especially given the changes to github’s leadership.
One minor note - on mobile safari there didn’t seem to be any state update on press of buttons, and submission was not clear until the backend server seemed to respond. My internet connection is a little slow and it was unclear tapping the button worked. I would expect a little loading state or at least ui to show the button as disabled during submission.
From their docs, apparently it just modifies the source code, although their LOC didn't change when they hit save in their video demo, so I'm not sure.
https://docs.onedev.io/tutorials/code/code-review#free-style...
I recall looking at it maybe 2-3 years ago and deciding against it. And it never seemed to get traction in the selfhosted community either.
...but I can't for the life of me recall why. Definitely wasn't a radioactive red flag issue...but some aspect around CI wasn't for me.
In general though with things like this that carry an open license and have a docker image you're better off trying it yourself than listening to randoms like me
For me the bus factor was a bit of a red flag, plus I prefer the layout in forgejo/gitea. Also didn't like that there wasn't really any obvious way to link in an external CI, and of course it's written in java so had that to factor in too.
This is why I dropped it. The CI/CD configurations were some weird proprietary format where as gitlab/gitea/forejo are all (mostly) feature compliant with my already existing github workflow files
I evaluated moving from Gitea to OneDev before Gitea had CI. OneDev was useable, I didn't mind it, but I don't run java anywhere else so I decided against adopting it. A few years later and now Gitea/Forgejo are at feature parity.
Seems like heavier version of gitea with a pricing section.
Ooh! My interest is peaked seeing it is written in Java.
Fossil is that you?
Fossil started as "not invented here", but it has grown into something I like a lot more than Git. Knowing how to use a version control system should be an incidental skill (akin to simple shell commands like "cp" and "ln"), not something that needs to be mentioned in a job posting's role description.
I also appreciate that the default workflow for undoing bad merges is a whiteout rather than a true "delete".
To each his own, but having worked with CVS, SVN, Perforce, Git, and Fossil, the centralized model is much less work for release engineering and administration most of the time. If I were a maintainer of the Linux kernel of one of the many Linux distros where you have potentially thousands of contributors to one codebase, I would use git because it scales up better.
However, I wouldn't underestimate the value of scaling down well, especially for all the people around here building some startup out of a barndominium. A VCS that includes its own GUI-based admin tool and is simple enough to used by some high school intro to web design class is a good thing in my book.
I was turned off by the necessity of using users and permissions; it feels unnecessary for local development and kind of a PITA if you have many repos.
It works exactly as advertised though; my gripes aren't technical.
[dead]
Why do people self-host things like this instead of Github or Gitlab? I don't want to maintain more services for my services. Who has time for that.
A better question is why does it take any time to maintain a tool like this? I spend zero time maintaining my open-source browser (Firefox). It just periodically updates itself and everything just works. I maybe spend a bit of time maintaining my IDE by updating settings and installing plugins for it, but nothing onerous.
A tool like this is not fundamentally more complex than a browser or a full-fledged IDE.
Our gitea instance had roughly five minutes of downtime in total over the past year, just to upgrade gitea itself. All in the middle of the night. How much downtime has GitHub seen over the same period, and how many people's work was affected by that?
I've been hosting a git service for quite a while now and it's maybe around half an hour per year of maintenance work. It's totally worth it in my opinion, it's so much better on almost every way ... One big reason is decentralization. Full control of data, change what you want, then things like the current npmjs attack show the downsides of having everyone using the same thing, and so much more
Backups, OS upgrades, version upgrades, firewall management, DDoS management. I just find self-hosting to be excessive to do right.
its not that hard though, and to be honest I trust myself more than a large org like microsoft to get that right
tinkering with services and networks and the whole self-hosting concept is pretty fun for many people.
One answer might be to avoid LLMs training off the intellectual property that your humans typed out for you. But as LLM code generation tools take off, it's a losing battle for most orgs to prevent staff from using LLMs to generate the code in the first place, so this particular advantage is being subverted.
This probably only matters for 1-2 years tops. LLMs are taking off pretty fast.
Especially as self-hosting means loosing the community aspect of GitHub. Every potential contributor already has an account. Every new team member already knows how to use it.
You’re assuming people are self-hosting open source projects on their gut servers. That’s often not the case. Even if it were, GitHub irked a lot of people using their code to train Copilot.
I self-host gitea. It took maybe 5 minutes to set up on TrueNAS and even that was only because I wanted to set up different datasets so I could snapshot independently. I love it. I have privacy. Integrating into a backup strategy is quite easy —- it goes along with the rest of my off-site NAS backup without me needing to retain local clones on my desktop. And my CI runners are substantially faster than what I get through GitHub Actions.
The complexity and maintenance burden of self-hosting is way overblown. The benefits are often understated and the deficiencies of whatever hosted service left unaddressed.
Microsoft/GitHub has no model training. How do you think Copilot works? Also if you provide open source, people and companies are gonna use it.
When I publish open source code, I don't mind if people or companies use it, or maybe even learn from it. What I don't like is feeding it into a giant plagiarism machine that is perpetuating the centralization of power on the internet.
I mean git was exactly designed to be decentralized
because: 1) privacy - don't want projects leaving a closed circle of people 2) compliance - you have to self-host and gitlab/github are way too expensive for what they provide when open-source alternatives exist 3) you just want to say fuck you to coorperate (nothing is free) and join the clippy movement.
As a mirror of my GitHub repositories following the 3-2-1 backup principle.