That is what we have been doing for quite some time now, from what I gathered. Every time I see something becoming popular, I am like "Hmm, I've seen this before", and I really have. They just gave it a fancier name with a fancier logo and did some marketing and there you go, old is new.
Apparently they have issues with self-hosting and basic git usage so I am not surprised, but yes, so many open source advocates, yet they literally depend on Microsoft, a bit too much.
> but yes, so many open source advocates, yet they literally depend on Microsoft, a bit too much.
I have abandoned github and even gitlab for all intents and purposes. But there's another side to consider in this.
It's always risky for the FOSS community to depend on a service that doesn't offer interoperability and freedom of migration. Ironically, Github is such a service built on a tool (git) that's built for maximum interop and migration. But the popularity of Github among the developer community isn't an accident. They worked really hard during their early stages as a startup, to gain the trust of community. Nobody foresaw Microsoft buying them at that stage (though you should really just assume that it would happen eventually).
The reluctance of a lot of them to abandon the platform can be attributed to lack of principles - IF it was an isolated incident. But we see the same story repeating with several development platforms. NPM is an example. PyPI and crates.io are still independent, as far as I know. But they aren't free of corporate influences either. No matter how much we try to avoid them, the companies just buy their way into these platforms when they become popular enough. I'm not happy with this. But I don't know a solution either.
Reading what you quoted, no it is not, as long as you contribute to free software or you have projects that are open source. Not just your personal homepage. If you only have a personal homepage and nothing else that is open source, then they have a problem.
Which makes it not really a suitable replacement for GitHub, which is my entire point.
Keep in mind, I'm not saying Codeberg is bad, but it's terms of use are pretty clear in the sense that they only really want FOSS and anyone who has something other than FOSS better look elsewhere. GitHub allowed you to basically put up anything that's "yours" and the license wasn't really their concern - that isn't the case with Codeberg. It's not about price or anything either; it'd be fine if the offer was "either give us 5$ for the privilege of private repositories or only publish and contribute public FOSS code" - I'm fine paying cash for that if need be.
One of the big draws of GitHub (and what got me to properly learn git) back in the day with GitHub Pages in particular was "I can write an HTML page, do a git push and anyone can see it". Then you throw on top an SSG (GitHub had out of the box support for Jekyll, but back then you could rig Travis CI up for other page generators if you knew what you were doing), and with a bit of technical knowledge, anyone could host a blog without the full on server stack. Codeberg cannot provide that sort of experience with their current terms of service.
Even sourcehut has, from what I can tell, a more lenient approach to what they provide (and the only reason why I wouldn't recommend sourcehut as a GitHub replacement is because git-by-email isn't really workable for most people anymore). They encourage FOSS licensing, but from what I can tell don't force it in their platform policies. (The only thing they openly ban is cryptocurrency related projects, which seems fair because cryptocurrency is pretty much always associated with platform abuse.)
I mean, it is arguably much easier to just write the HTML page and upload it with FTP and everyone can see it. I never understood why github became a popular place to host your site in the first place.
> I never understood why github became a popular place to host your site in the first place.
Easy: it was free, it was accessible to people that couldn't spend money for a hosting provider (read: high schoolers) and didn't impose arbitrary restrictions on what you were hosting.
Back then, your options as a high school student were basically to either try and reskin a closed off platform as much as you could (Tumblr could do that, but GitHub Pages also released in the time period where platforms were cracking down on all user customization larger than "what is my avatar") or to accept that the site you wanted to publish your stuff on could disappear at any moment the sketchy hosting provider that provided you a small amount of storage determined your bandwidth costs meant upselling you on the premium plan.
GitHub didn't impose those restrictions in exchange for being a bit less interactive when it came to publishing things (so no such thing as a comment section without using Disqus or something like that, and chances are you didn't need the comments anyways so win-win) That's why it got a lot more popular than just using an FTP server.
There are multiple reasons why FTP by itself became obsolete. Some of them I can think of off the top of my head:
1) Passive mode. What is it and why do I need it? Well, you see, back in the old days, .... It took way too long for this critical "option" to become well supported and used by default.
2) Text mode. No, I don't want you to corrupt some of my files based on half-baked heuristics about what is and isn't a text file, and it doesn't make any sense to rewrite line endings anymore anyway.
3) Transport security. FTPS should have become the standard decades ago, but it still isn't to this day. If you want to actually transfer files using an FTP-like interface today, you use SFTP, which is a totally different protocol built on SSH.
chrome and firefox dropped support for it 5 years or so ago, it has had a lot of security issues over the years, was annoying over NAT, and there are better options for secure bulk transfers (sftp, rsync, etc)
Finding an HTTP+FTP server was easier than finding github. Your OS probably has a FTP client installed already, but finding another one is easier than finding and most definitely easier than learning git.
And if you already knew how to write/make HTML you'd for sure already know all of that too.
This is definitely a matter of perspective. I have had a Github account since 2010, and git comes installed on Linux and macOS.
I don't always have a server available to host an HTTP+FTP server on. Or want to pay for one, or spend time setting one up. I can trust that Github Pages will have reasonable uptime, and I won't have to monitor it at all.
> And if you already knew how to write/make HTML you'd for sure already know all of that too.
This seems unnecessarily aggressive, and I don't really understand where it's coming from.
BTW, you can absolutely host plain HTML with Github Pages. No SSG required.
> And if you already knew how to write/make HTML you'd for sure already know all of that too.
That's a completely false statement. My kid took very basic programming classes in school which covered HTML so they could build webpages, which is a fantastic instant-results method. Hooray, now the class is finished, he wants to put it on the web. Just like millions of other kids who couldn't even spell FTP.
There was a lot of sites that provided some cpanel-like option as long as you're ok with yourcoolname.weirdhostingname.com. I believe they all came with a filebrowser and the always present public_html folder.
There was geocities (now gone) and a couple of *.tk domains that would inject their ads all over your page. Neither makes a great substitute for GitHub pages these days.
I touched on the issues with FTP itself in another comment, but who can forget the issues with HTTP+FTP, like: modes (644 or 755? wait, what is a umask?), .htaccess, MIME mappings, "why isn't index.html working?", etc. Every place had a different httpd config and a different person you had to email to (hopefully) get it fixed.
"hate" is not even an argument. It is obviously for those who dislike React or put it in another way: do not like to or would rather not work with React.
It works better than "just like" in the sense that it also takes care of things like CSRF, POST/GET params, request/response types etc for basically free.
No, I mean, for example uninitialized pointers are a huge red flag, so seeing one not set to NULL is honestly shocking, especially in crypto code where a stray pointer can lead to crashes or subtle security issues.
reply