Live data from Hacker News

Sourcehut welcomes Bitbucket refugees

sourcehut.org

91–100 of 219 posts

Re: Sourcehut welcomes Bitbucket refugees

#91
post #65

Earlier quoted context omitted.

It's written in Python so as soon as they have enough users it will be as slow as any webpage with tons of JS. Thankfully, that CPU load won't be on the client side... so it's still an improvement

I recommend you relax your convictions about Python performance a bit. Server-side bottlenecks are more often than not database reads/writes and other IO. And the few CPU-intensive operations can be delegated to libraries written in C. Pure Python is slow for CPU-intensive tasks, but that doesn't mean that a Python webserver is necessarily slow.

So what you're saying is that the author of Sourcehat is expected to rewrite Flask, Jinja2, etc in C?

As an example, https://git.sr.ht/~sircmpwn/git.sr.ht/tree/master/gitsrht takes 600-800 ms to generate, and it's probably heavily cached already. What will happen when they get more users? The site will be unbearably slow, unless the guy starts spending thousands in servers.

Re: Sourcehut welcomes Bitbucket refugees

#92

People seem pretty interested in keeping their pre-git source control system, even if it means switching repository hosts. I know the default attitude is "they're just curmudgeons who don't want to change," but Hg could have some advantages.

Mercurial shouldn't be considered a pre-git source control system.

It's initial release date was actually 12 days after git and it is far more comparable to git than it is to SVN and other pre-git version control systems.

Re: Sourcehut welcomes Bitbucket refugees

#93
post #74

Serious questions... What does mercurial offer that git doesn’t? Is the transition to git difficult for projects currently housed in a mercurial repository?

Technically I think Mercurial would be better for engineering wise in the long term.

Mercurial has a single implementation (Git has 5), and they greatly discourage anyone from implementing a second. This gives them a single source of truth for the implementation.

Mercurial has better hooks in place. If a company (such as Google or Facebook) wants to change the behavior of an action, they can override or hook into a specific spot in the code and change how things work. So I could create an extension that completely changes some aspect of how Mercurial works without needing to fork it (unlike Git, where Microsoft had to release a fork of it to support their file system change).

It had better windows support than Git did for a long time. I believe it is still better because you don't rely on MinGW or some other Linux abstraction layer (though it uses python).

Re: Sourcehut welcomes Bitbucket refugees

#94

People seem pretty interested in keeping their pre-git source control system, even if it means switching repository hosts. I know the default attitude is "they're just curmudgeons who don't want to change," but Hg could have some advantages.

For me, I started using Hg before I started using Git, so I have about as many Hg repos as Git repos.

I also started using Bitbucket, back when that was the only option (they didn't have git support until Atlassian bought them).

I have no personal desire to transform these Hg repos into Git. That just seems like busy work.

Bitbucket is causing work for me (granted I never paid them a dime over these last 10+ years, so I have nothing to complain about).

My choices are to migrate these repos from Hg to git, or move hosts. I'm pretty sure I'm going to move hosts, seems like less work.

Re: Sourcehut welcomes Bitbucket refugees

#95
post #91

Earlier quoted context omitted.

I recommend you relax your convictions about Python performance a bit. Server-side bottlenecks are more often than not database reads/writes and other IO. And the few CPU-intensive operations can be delegated to libraries written in C. Pure Python is slow for CPU-intensive tasks, but that doesn't mean that a Python webserver is necessarily slow.

So what you're saying is that the author of Sourcehat is expected to rewrite Flask, Jinja2, etc in C? As an example, https://git.sr.ht/~sircmpwn/git.sr.ht/tree/master/gitsrht takes 600-800 ms to generate, and it's probably heavily cached already. What will happen when they get more users? The site will be unbearably slow, unless the guy starts spending thousands in servers.

I imagine that the CPU-intensive parts of Flask and Jinja2 are already written in C. Much of Python's standard library is.

800ms is a reasonable response time, and if they scale up according to their userbase, they will hopefully maintain that time.

(Also, we don't know how much of that 800ms is Python vs. IO)

Re: Sourcehut welcomes Bitbucket refugees

#96
I am looking to preserve the pull requests and corresponding comment threads from bitbucket. I'm thinking the way to go might be to save static HTML of the pages and host them somewhere, modifying the links to issues to point to migrated ones, and links to PRs to the hosted pages. Anyone else thinking of trying this approach? Advice, criticism?

Re: Sourcehut welcomes Bitbucket refugees

#97
post #91

Earlier quoted context omitted.

So what you're saying is that the author of Sourcehat is expected to rewrite Flask, Jinja2, etc in C? As an example, https://git.sr.ht/~sircmpwn/git.sr.ht/tree/master/gitsrht takes 600-800 ms to generate, and it's probably heavily cached already. What will happen when they get more users? The site will be unbearably slow, unless the guy starts spending thousands in servers.

I imagine that the CPU-intensive parts of Flask and Jinja2 are already written in C. Much of Python's standard library is. 800ms is a reasonable response time, and if they scale up according to their userbase, they will hopefully maintain that time. (Also, we don't know how much of that 800ms is Python vs. IO)

https://github.com/pallets/flask

https://github.com/pallets/jinja

0% C

Also 800 ms is NOT a reasonable response time to generate what basically is a bunch of text, that is absurd, but I guess this is the baseline in 2019.

I trust all IO is cached. The author can confirm it. This is just how slow Python is.

Re: Sourcehut welcomes Bitbucket refugees

#98
post #41

They violently break all the recent frontend best practices. Where is the React or Vie, SPA architecture, tons of JS? There should be a federal law prohibiting making fast and simple UIs so that nobody will have concerns that the UI frameworks war leads us to great future.

What a healthy dose of sarcasm on top of a healthy dose of gui layer.

Re: Sourcehut welcomes Bitbucket refugees

#99
post #74

Serious questions... What does mercurial offer that git doesn’t? Is the transition to git difficult for projects currently housed in a mercurial repository?

There are a few good things about it compared to git (and a few bad ones). One I like is that it has an excellent GUI that is cross platform, called TortoiseHg. I know hackers can be a bit snobbish about GUIs but I really think a GUI is essential for version control: flicking through the revision graph in one pane while looking at the modified files in another and a file's changes in a third is much more efficient than anything on the command line. And picking source and destination commits for a rebase is much easier visually on the commit graph than making note of hashes on the command line. Plus, at our company we do have a few people who use version control but are a bit less compsci focused.

Related question: does anyone know of a good git GUI that works on Windows and Linux? (Ideally, but not essentially, free.) I tried GitKraken and it failed at the first thing I tried to do with it (I wanted to stage a file I had just created, but it didn't have a way to display untracked files).

Re: Sourcehut welcomes Bitbucket refugees

#100
post #41

They violently break all the recent frontend best practices. Where is the React or Vie, SPA architecture, tons of JS? There should be a federal law prohibiting making fast and simple UIs so that nobody will have concerns that the UI frameworks war leads us to great future.

Insightful and hilarious sarcasm delivering a unique perspective!
Post reply on HN