> We (the Git project) got control of the git-scm.com domain this year. We
> have never really had an "official" website, but I think a lot of people
> consider this to be one.
So, uh, git-scm.com wasn't an official website all these years?
Maybe so, but since git-scm.com's 2012-05-05 redesign [1], the professional visual design, the new footer, the internally-hosted download pages, and the verbiage has no longer given the impression of an "unofficial" site. Compare with the old design used until 2012-05-04 [2].
I was going to bring it up in my original comment, but felt that it might come off as too negative: GitHub has made out handsomely by unsuspecting folks conflating Git and GitHub. So it's not really surprising. More expected.
If you didn't see it, there was another email sent out that discusses this and other issues with the Git mark [0]
The trademark policy can be found at [1]
A few quotes to summarise:
----
We approached Conservancy in Feb 2013 about getting a trademark on Git to ensure that anything calling itself "Git" remained interoperable with Git.
While the original idea was to prevent people from forking the software, breaking compatibility, and still calling it Git, the policy covers several other cases.
One is that you can't imply successorship. So you also can't fork the software, call it "Git++", and then tell everybody your implementation is the next big thing.
Another is that you can't use the mark in a way that implies association with or endorsement by the Git project. To some degree this is necessary to prevent dilution of the mark for other uses, but there are also cases we directly want to prevent.
The USPTO initially rejected our application as confusingly similar to the existing trademark on GitHub, which was filed in 2008. While one might imagine where the "Git" in GitHub comes from, by the time we applied to the USPTO, both marks had been widely used in parallel for years. So we worked out an agreement with GitHub which basically says "we are mutually OK with the other trademark existing".
So GitHub is essentially outside the scope of the trademark policy, due to the history. We also decided to explicitly grandfather some major projects that were using similar portmanteaus, but which had generally been good citizens of the Git ecosystem (building on Git in a useful way, not breaking compatibility). Those include GitLab, JGit, libgit2, and some others. The reasoning was generally that it would be a big pain for those projects, which have established their own brands, to have to switch names. It's hard to hold them responsible for picking a name that violated a policy that didn't yet exist.
----
I too have come across the Git/GitHub confusion far too many times, and it is extremely unfortunate.
The worst aspect in my opinion is that because of this confusion a lot of the beauty and utility of Git, as a truly distributed version control system, is missed or not understood; it's assumed that using Git is the same thing as storing your code on a specific hosted service.
That said I think the Git Project Leadership Committee is doing a fantastic job and have never had cause to question any of the decisions they've made nor the direction they seem to be taking the project, in this issue and others.
This is very interesting. I run https://www.gitignore.io and this post highlights a lot of interesting things about git-scm.
1. GitHub is footing the bill — I'm paying for gitignore.io (although it's only costing me the annual domain)
2. The site uses 3 Dynos — Currently gitignore.io uses 1 Dyno on the free tier and I've recently moved the backend from Node to Swift to double / triple network performance based on my preliminary testing. I don't know why the site needs 3 Dynos because like the OP mentioned, it's a static site. I also use Cloudflare as a CDN which could dramatically improve git-scm's caching layer. It's not that helpful for me as most of my requests are dynamically created, but for a static site, it would drastically reduce Dyno traffic.
3. Access to Heroku seems to be an issue — I ran into the same problem and I'm finishing up a full continuous integration process to build and test my site on Travis. I basically want to approve a pull request and have the site fully tested though my Heroku pipeline, then have the PR landed in production.
4. Traffic - I don't know how many users he's got but I'm seeing about 60,000 MAU's and about 750,000 requests a month.
* Jason Long helped design my site and logo as well.
Your site doesn't work for me. It doesn't matter what I enter, (I tried Delphi, C#, Visual Basic, Windows) I only get "No result found".
Also your Tutorial Video doesn't match your current design. The colour scheme is off and instead of a "Generate" dropdown button there is a plain "Create" Button.
I'm on Chrome Version 55.0.2883.87 m on Windows.
I turned of uBlock Origin for your site.
You may be experiencing some caching problems. Also around the time you checked I was in the middle of pushing the swift site to Heroku so that may have introduced some issues as well. The new site has a "Create" button with no drop down — Can you please re-try https://www.gitignore.io/.
OK, I tried it at home. Another PC, another Provider, Chrome Version 56.0.2924.87, no uBlock, I even tried it in Inkognito Mode. The result is the same. https://imgur.com/a/Bo4Kq
Although it is a RoR app you still can cache a lot of thing out of the box. As others have pointed out, just using cloudflare as CDN would already help somewhat.
Recently I've seen a blog post about a company using RoR for generating a completely static website. Unfortunately I can't find it anymore.
The naive approach would be to use "wget -r" a locally running and "rsync" the generated html to the server but there might be some gotchas with that.
Ah yeah. I'm going to write a blog post on this in a few weeks, but basically I'm running tests using `wrk`. Here are the results I just got with a test (this is actually a bit abnormal), but note the requests per second, latency, and the transfer speed per second.
I am always amazed at how quickly Heroku gets prohibitively expensive when you start scaling.
When I ran https://jscompress.com/ on Heroku, I was up to $100 per month for 2 2x Dynos. Completely absurd for a simple one-page Node.js app. I put in a little work moving it to DigitalOcean, and had it running great (and faster) on a $10 VPS.
I get the appeal of Heroku (I have used it several times), but man sometimes it feels like gouging when you can least afford it.
Heroku is like a cradle: it gives you instant comfort and feeds you all you need without effort when you're newborn. But when you're ready to start walking by yourself, it definitely will strand you.
Conservatively, the people in this conversation make $5 million per year total, the software (git) contributes billions, and we are discussing how to better allocate $230 per month. Open source economics is fascinating.
If you think about it in terms of hourly contracting rate, the opportunity cost of participating in this conversation could easily cost more than $230.
Speaking of popular software that doesn't have its own website, the PuTTY developers have never bothered with getting a domain name specifically for PuTTY (http://www.chiark.greenend.org.uk/~sgtatham/putty/). I'm not actually entirely sure what the rest of the site/domain is meant to be for either.
Pretty sure PuTTY is a one man job and the page is just a personal one hosted on chiark.greenend.org.uk, which seems to be just a server run by his mate
putty.org is not affiliated with the PuTTY project. The domain is registered by one of the founders of bitvise, which explains the advertising for their products on the site.
I wonder how hard it would be to convince folks to drop their expensive setups in favor of nearly $0 static sites, as well as how much up front cost they'd be willing to shovel out for the transition. S3 + CDN (+ Lambdas optionally) feels really ready to me for almost any straightforward "website." For most things GitHub/Lab pages is an easy path to that.
A lot of folks who have static websites aren't technical and invested thousands of dollars for a WP website. If their site already runs, you wouldn't be providing anything.
...unless they have to pay noticeable money for WP hosting due to serious load, or were bitten by security problems.
A free business idea: write a converter from WP to Jekyll (or Hugo) that converts 95% of a typical WP site right, sell total conversion services, maybe reselling hosting, too.
I have several WordPress sites (mostly "abandoned"/no longer updated) that I would love to convert to static sites. I would happily pay a decent sum for a tool that could completely handle that conversion/migration.
I used https://de.wordpress.org/plugins/simply-static/ to convert a WP site with 10.000 pages. Took about 60 minutes so i had to increase PHPs max_execution_time. I also tested some other plugins before but most don't worked for me.
I had to turn off HTTPS for the generation time and reportet it as a bug to the developers.
If it were my site, I think I wouldn't even bother with the search: just stick it all on S3, and have one of those 'Google custom search' or similar boxes, so it's static as far as your site's concerned, and just redirects to Google with the `site:foo` filter.
I don't really have a handle on what S3 costs 'at scale', but I think I'm willing to bet it would knock at least the 0 off the end.
Search could easily be done if content is indexed in json files.
CDN hosting of a static site is nearly $0 so def the best option in this case. Plenty of providers give free PRO service to OSS projects as well (i.e. netlify)
Lunr.js is designed for exactly that use-case and the example shows that workflow pumping a bunch of documents into an index and saving it as JSON which is loaded client-side:
A linode vm's cost is not measured in its price tag but in how much effort it takes to maintain. Updates, security advisories, hypervisor crashes, crashes under sudden unexpected load, crashes because you're on vacation and you are having too much uninterrupted fun, ...
As a famous writer once said: "ain't nobody got time for dat."
The money it costs to get someone to fix it. That person isn't free, unless this is their hobby.
It's not about uptime, it's about the service existing at all. Even if you are fine with an hour downtime per day; at the end of that hour, you'll still need to bring it back online. The "aaS" part is about taking that load off. The nines are a corollary.
Concretely: a dedicated server leaves you with a lot of extra work. A packaged, managed service doesn't. E.g.: s3 for static files vs an nginx server on a VM. Even if they cost the same, s3 would still be a better option for git-scm.org.
> A linode vm's cost is not measured in its price tag but in how much effort it takes to maintain. Updates, security advisories, hypervisor crashes, crashes under sudden unexpected load, crashes because you're on vacation and you are having too much uninterrupted fun, ...
If I had a choice between that and ~$1800/year?
If you don't want to do sysadmin work at the rate of ~$300/hr, that is your business.
The generated Rust API docs, which are uploaded to https://doc.rust-lang.org/std/ (but also the same ones you can download), do something where they generate an index of the entire site as a JavaScript object, so searches can happen client-side. So it's a static website, but search functionality works.
Why even bother paying for S3? Just use a static site generator and put it on github pages, github is already paying for the heroku vms so I bet they'd be happy to pay less to use their own infrastructure even if the git-scm.com/org site uses more than their bandwidth requirements.
Well, I was thinking the same, if open source projects from facebook have all the documentation hosted using GHP why not git? And for the search option they use algolia and I think it's free for documentation projects.
I've used Algolia [1] and Swiftype [2] in the past for search on static websites, but recently experimented with lunr.js [3] for our company playbook (built with GitHub pages): http://playbook.wiredcraft.com/
I still want to separate the index in its own JSON file, but so far, so good. Search is fast and index is rebuilt automatically.
At 5 Watts and $0.30 per kilowatt-hour, a Raspberry Pi would cost $1.08/month to run.
With 1 free GB and $0.09/GB-month, S3 would be able to deliver 13 GB/month at a cost of $1.08/month.
So, RasPi at home gives you "unlimited" egress and a fixed cost, but you have increased latency, a rather small outgoing bandwidth (most likely), and all the downsides of running your own server.
S3 gives you unlimited bandwidth, low latency, and no server maintenance, but it's only competitive on price if you don't exceed 12GB of egress.
Overall I prefer S3, even if I think their egress prices are ridiculous. RasPi at home has some geeky cool factor, though...
NOTE: $0.30/kwh is basically what I pay (California) for any additional usage. These equations will favor home hosting if your electricity is cheaper.
A raspberry pi is also not a CDN. Why even manage servers when all you need is a static site? Deploy to a CDN and if properly configured, everything just works.
Especially with the site being considered in 'maintenance mode', I doubt they want to manage a server aside from the other things they need to do.
I know someone who optimized searching the leaked Adobe database (of a few hundred gigabytes if I remember correctly) on a Pi to a sub-second search. That was super impressive and the method used wasn't even obscure (binary search). The same doesn't apply here, but I'm trying to say a Pi isn't entirely worthless.
For example, what pages get accessed the most anyway? I'm guessing the latest source code and maybe the latest release, though most people probably just apt-get git instead so it's probably mostly the source code. Then there are man pages and some other info pages, if I remember correctly. Sounds like the latest release + 90% of those text pages can easily fit in RAM. So memcached? Nah, the Linux kernel happily caches the files that you read from disk.
I don't know the actual numbers but it doesn't sound infeasible to me. A $230 hosting bill is very heavy though, I guess you'd need some serious fiber as well to provide the uplink. But again, without numbers it's all "maybe" and "probably".
Yeah, that was my project, it worked quite nicely. However, the biggest reason was that my Raspberry Pi was my only server at that point, and besides, tranferring 10GB out of my home connection to a VPS would've been too slow for my impatient self. I think the file was stripped of all other data (which brought it down to about 4GB) and I put it on a thumb drive instead.
Nowadays I would have used a VPS for that. The point with S3 or any other cloud solution is that they make sure you're up and running. Even though it might still be useful, the need for good service monitoring is as good as gone when moving to one of these cloud based platforms. And then I'm not even taking into account the time you have to invest in setting up and configuring a RPi properly vs just pushing a repo to Github Pages, or uploading a zip file to S3.
Heroku or other cloud platforms can be crazy expensive, but for static file hosting, S3 or Github Pages is more than enough and quite affordable.
You could put the site itself on an external drive via USB - and ideally most of it the access be read-only for a static site, so the life of the sdcard shouldn't be as big of a concern.
That said I'd agree, Raspberry Pi's a great but not quite fast enough for serving a high-traffic website.
That's not sarcasm. It's not like anyone here has numbers to say I'm wrong, and I'm not hearing any good arguments as to why it's a bad idea. I've had my blog (which does 3 mysql queries for each pageload) hit the HN front page with 105KB/s uplink and either a Pentium 3 or Intel Atom as CPU (I forgot when I switched servers). In any case, something much like a Pi can handle HN front-page traffic with a database. And people are downvoting hosting a website that's even less heavy on a Pi? Unless it's 500 hits per second, I don't get it.
For a static website you can easily live with 10000 users on this machine. But lets say you need more, for 40 dollars you get 30Go of RAM and a 250 Mbps pipe (https://www.ovh.com/fr/vps/vps-cloud-ram.xml). To serve HTML pages plus a bunch of css files that should be ok.
Alternatively, they can use Scaleway[1] VPS. Start at 3€/month and if necessary scale up to 6 cores, 8 GB memory, 200GB SSD and unmetered bandwidth (200 Mbit/s) for 10€/month. That should be enough for a static website.
Some armchair speculation: the price Gitlab and Atlassian would pay to have one link each up there would probably dwarf the current monthly hosting costs.
Not sure if the "try.github.io" link should count as a link to Github, but most of the others do (e.g., github.com/google).
Further armchair speculation: you could extract more money from one of them for having an "exclusive" link than you could from both of them having one link each.
Indeed. I'm having a hard understanding why Github, Gitlab or Attlasian didn't jump already in requesting full ownership of the project. This is the clearly the most important open source project to their core business.
If you're not aware, many of the core contributors are employed by these companies, or extensions are built internally at these companies and then released opens source.
For example, the long time maintainer Junio works at Google and peff at GitHub.
I think the current management of the project, by the Project Leadership Committee, is working well and the project would gain little by coming under the direct management of any single company.
In a different thread, peff (author of the original post we're discussing here) requested input from the community about adding links to paid content to the site.
You can see the end of the thread here [0] and the pull request it was discussing here [1]
The thinking in that thread, which I think would apply similarly to this case, was:
I think I'm inclined to try it, as long as it's kept in a separate "paid training" section, and is open to everybody. If it becomes a burden, we can cut it out later. I think the important thing is that it be equally open to everybody or nobody, but not just "some". So we'll go with everybody for now, and switch to nobody later if need be.
I agree that they would probably pay well for the chance to have a link on the homepage of git, but if it is done it should be done fairly for all involved, or not at all.
Or just throw a CDN with a decent cache lifetime in front of the Rails app and scale the Heroku side way down if you don't want to go through the hastle of changing anything. It's pretty much static after all.
I was thinking the same thing after reviewing the repo and output HTML but I wonder if that would really lower the monthly hosting costs for the Heroku instance and the various addons. It would be simple to modify the RoR app to output the proper caching headers that would allow any CDN to cache the HTML output and obey the various cache limits, but on demand rendering the output from time to time is still required once the cache expires.
I think moving the site to a normal static site generator (like Jekyll) would deliver the most bang for the buck but would be quite the transition. The site would only need to be built upon a new commit and with the proper site generator it will only update the underlying HTML files that require a change. Then syncing the update HTML to whatever CDN is chosen.
Its all armchair engineering, but it may be feasible to keep the current setup, but replace the current deployment process with starting up the application and snapshotting it with a crawl from wget or similar.
This was my thinking and experience when I set out to build Cachoid[0]. There's so much to gain from caching stuff in RAM it should be ubiquitous. The thing is CDNs don't always have the scale to stick all tenants in RAM. Hence the caching to disk.
> Do we really need three expensive dynos, or a $50/mo database plan?
Sounds like there's the chance to optimize for what is, as they say, a static website. Why for a database that you're not using? (And what kind of a database plan do you have when it costs $50/month when it's apparently a (nearly?) empty database?!)
While moving to a static site is the cheapest long term, simplest solution is to switch to a cheaper dyno type. The message says they're running on three 1GB dynos. Change that to six hobby tier (512mb) ones and you'll get the similar performance for $42/mo (instead of $150).
No code changes. No anything. Just a twiddling the dyno tier and count.
I don't see any issue in github paying for this page and i don't think, that this page will no longer exists when github decides not to pay for it anymore.
There are enough companies who just overtake. Google, heroku whatever.
But it would probably a good idea to try to help Jim in his work.
As far as I understand it nobody but the git team is paying for hosting. Why neither Github or Heroku are paying for this? They are built on top of git. Millions of tech dollars go to political causes right now yet nobody is willing to give $230/mo of free hosting to git website, the most used VCS today? Talk about priorities. And it's not the first time, plenty of open source projects used by billion dollar companies receive 0 of funding.
Edit: GIthub seems to be paying for that but Heroku shouldn't even bill them.
It was a website built by a GitHub co-founder on his own initiative, who happened to also be a git contributor. It wasn't particularly a thing that git the open-source project requested.
> Please don't insinuate that someone hasn't read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that."
