Post 9zIDsbiALIluG3ajJY by lain@lain.com
(DIR) More posts by lain@lain.com
(DIR) Post #9zGOZi5792VNgyb5Q8 by sir@cmpwn.com
2020-09-17T22:17:14Z
1 likes, 3 repeats
Compared to GitHub and GitLab, SourceHut wins by objective measurements in all of these categories:✓ Free software✓ Reliability✓ Performance
(DIR) Post #9zGOqSyIZnPPkiOoXw by lanodan@queer.hacktivis.me
2020-09-17T22:24:26.715722Z
0 likes, 0 repeats
@sir And even if the flagship instance wouldn't be reliable enough it can be self-hosted so that the downtimes are even further controlled.
(DIR) Post #9zGOsR0eqFmoFMRQA4 by lain@lain.com
2020-09-17T22:24:47.915804Z
4 likes, 0 repeats
@sir and loses in the following::lazer_x: having features people use and need every daySrht is great software but you'll never convince people to switch by showing its better in some way they don't care much about.
(DIR) Post #9zGOz7U3pvIViRNkTA by methyltheobromine@netzsphaere.xyz
2020-09-17T22:26:00.821177Z
0 likes, 0 repeats
@sir I like gitea
(DIR) Post #9zGP8OSs4V06zGFPwe by sir@cmpwn.com
2020-09-17T22:25:16Z
1 likes, 1 repeats
@lanodan and during outages, the global mail system continues to be its reliable, fault-tolerant self, delivering messages and allowing collaboration to continue, then catching the servers up on what they missed once things are online again
(DIR) Post #9zGPJ7QNlb8pK7CJtI by sir@cmpwn.com
2020-09-17T22:25:40Z
0 likes, 0 repeats
@lain github fails this measure, too. Different users want different features.
(DIR) Post #9zGPJ7c546UzuOff7o by lain@lain.com
2020-09-17T22:29:35.381067Z
0 likes, 0 repeats
@sir very true, but that's why it's not very meaningful to make a comparisons in terms of 'better'. Srht is a lot better than GitHub, gitlab, whatever in many ways, but still I won't use it because it doesn't do what I need for Pleroma dev.
(DIR) Post #9zGPqh5oArlvVDaHsO by sir@cmpwn.com
2020-09-17T22:31:09Z
0 likes, 0 repeats
@lain the difference is that I gave objective measures by which sr.ht is objectively better, and you responded with a subjective measure which is up to interpretation
(DIR) Post #9zGPqhH9UgqW4OtLYe by lain@lain.com
2020-09-17T22:35:40.123040Z
3 likes, 0 repeats
@sir turns out, the gnu 'yes' command has better performance than srht. More reliable, too. And that with a lot less lines of code.
(DIR) Post #9zGPsctClyzb2sbutM by feld@bikeshed.party
2020-09-17T22:36:00.033584Z
0 likes, 0 repeats
@lain @sir sad but true, users don't care about free software, performance, "reliability". Those are technical things. They just want it to solve their problems so they can tolerate their 9-5 job.
(DIR) Post #9zGQ78lX3RcRxhwUsq by moody@mastodon.sdf.org
2020-09-17T22:38:38Z
0 likes, 0 repeats
@sir Being open source is a great benefit, thank you and the contributors for making a great systems :)
(DIR) Post #9zGQA8kvXzeYnh5dlQ by lain@lain.com
2020-09-17T22:39:11.602861Z
1 likes, 0 repeats
@feld @sir I do care about free software, and I do care about the other things too, but they are relative. If I can spend 2 euro a month to host some naked git repo or 10 euro a month to host a full featured source management system with CI, I don't care that the first is more efficient in some technical way. and if I could pay 100 euro a month to make all those stupid CI issues that we're having go away, I'd do that too
(DIR) Post #9zGQErE69IULsiz3lw by sir@cmpwn.com
2020-09-17T22:36:56Z
0 likes, 0 repeats
@lain I can argue in bad faith too, I'll thank you for not indulging in it
(DIR) Post #9zGQErRvJtY0ZbS6K0 by lain@lain.com
2020-09-17T22:40:02.721803Z
0 likes, 0 repeats
@sir plz
(DIR) Post #9zGQGIKuq9pAFdrGFs by feld@bikeshed.party
2020-09-17T22:40:19.312459Z
0 likes, 0 repeats
@lain @sir we are a very specific class of users though, unlikely to make giant waves in society or pop cultureif you're looking to change the world, aim for the majority
(DIR) Post #9zGQQYPruVgb1B4CH2 by lnxw37a2@pleroma.soykaf.com
2020-09-17T22:42:10.248601Z
2 likes, 0 repeats
@lain @sir Not just Pleroma. Lots of people rarely use electronic mail (including me), so enforcing e-mail based workflows is an uncrossable obstacle. I'd even be better with sending flash drives via postal mail (p-mail).I understand that srht targets projects and people where that works, so I understand that. It just won't ever work for me with that workflow.
(DIR) Post #9zGQdbejB1GWpXEzFg by sir@cmpwn.com
2020-09-17T22:42:57Z
2 likes, 0 repeats
@lnxw37a2 @lain sr.ht offers a web workflow which just happens to be email underneath, the experience is funtionally identical to github et al
(DIR) Post #9zGQdyy0VVLz7zRCzo by sir@cmpwn.com
2020-09-17T22:43:05Z
3 likes, 0 repeats
@lnxw37a2 @lain and get an email address you pleb
(DIR) Post #9zGYGnaXRg2aoKutrE by dathagerty@mastodon.technology
2020-09-18T00:08:19Z
0 likes, 0 repeats
@sir it loses on JavaScript loaded, though.
(DIR) Post #9zGsp3uNGyhaM5oIHQ by merlin@fosstodon.org
2020-09-18T03:58:33Z
0 likes, 0 repeats
@sir still written in a scripting language.
(DIR) Post #9zHYCQlGZGvS0voNfs by sir@cmpwn.com
2020-09-18T11:42:48Z
0 likes, 0 repeats
@merlin (1) increasingly not true and (2) what of it?
(DIR) Post #9zHmLfoLNjNaecYK3c by iptq@mstdn.io
2020-09-18T14:18:39Z
0 likes, 0 repeats
@sir id like to hear more about these performance and reliability measurement criteria. if ur not weighing performance and reliability by amount of traffic then i fail to see how these metrics are accurate
(DIR) Post #9zHmeSPpPSzYbx2h5U by sir@cmpwn.com
2020-09-18T14:24:36Z
0 likes, 0 repeats
@iptq why does weighing them by traffic matter? It's not about being "fair", it's about who's online and who's in an outage.
(DIR) Post #9zHmqcvo8caOhTnscC by sir@cmpwn.com
2020-09-18T14:26:45Z
0 likes, 0 repeats
@iptq as for performance you can see the criteria for yourself here:https://forgeperf.org
(DIR) Post #9zHnZFAfKDyo2Y1nn6 by iptq@mstdn.io
2020-09-18T14:34:55Z
0 likes, 0 repeats
@sir ah, just realized that performance was referring to in-browser performance. yeah not really a big fan of heavy gitlab pages eitherwrt reliability, if sourcehut is only reliable because it has less traffic, then how am i to know that it won't have reliability issues as traffic increases? it's not about being fair, it's just about the meaning of reliability, like "oh i can have xxx uptime while serving yyy users" since having 100% uptime is easy with 0 traffic
(DIR) Post #9zHnyuPZ8EF7BUEfOy by sir@cmpwn.com
2020-09-18T14:39:28Z
1 likes, 0 repeats
@iptq whether or not it'll continue to be reliable as traffic increases is a valid and interesting question, but it's beside the point that I'm making, which is that sr.ht users today enjoy dramatically improved reliability compared to GitHub and GitLab.To answer your question directly, though, I also believe that sr.ht scales better than either, anyway. We have this level of reliability without actually putting very much effort into it - most of the hardcore availability improvements have been deferred to the beta. Once we get those in I see no reason why we wouldn't be even more reliable.Our engineering is just better. GitHub and GitLab have the same dysfunctional engineering culture which chases shiny things and builds rube goldberg machines. SourceHut focuses on reliable, simple, robust solutions.Also check out https://metrics.sr.ht, where our performance metrics are available for the public to browse and run queries against, and you can get a feel for how well our infrastructure would adapt to changes in load.
(DIR) Post #9zHo6yxC7wEZaZoaEi by iptq@mstdn.io
2020-09-18T14:38:17Z
0 likes, 0 repeats
@sir supposing the entirety of github suddenly switched over to sourcehut overnight, how much work/money would have to be put into ensuring that reliability wouldn't be impacted?
(DIR) Post #9zHo6zJAoDoagk68Ui by sir@cmpwn.com
2020-09-18T14:39:54Z
0 likes, 0 repeats
@iptq this is a stupid question because the entierty of github is not going to switch to sourcehut overnightObviously it would cripple us and require a massive investment to adjust for.
(DIR) Post #9zHoLhE4Jxcsx0iw9g by sir@cmpwn.com
2020-09-18T14:42:48Z
0 likes, 0 repeats
@iptq well, actually, our next-generation backend infrastructure that's in development has shown to scale up to 100,000+ requests per second, so maybe it'd be just fine once that gets rolled out everywhereThe bandwidth would probably become the bottleneck at that point and that can be solved with a phone call
(DIR) Post #9zHvsQgHYT3MsBTZ5s by sir@cmpwn.com
2020-09-18T16:07:24Z
0 likes, 0 repeats
@iptq FYI this discussion inspired me to document the scalability plans and do another re-evaluation of all of the growth rates and planning, details written up herehttps://man.sr.ht/ops/scale.md
(DIR) Post #9zI1wa7F1AY31ARtNg by parisni@social.interhop.org
2020-09-18T17:05:55.314195Z
0 likes, 0 repeats
@sir @iptq do you plan to use connection pooling to easily avoid being >= connection_max on postgres and also optimise connection life cycle ?
(DIR) Post #9zI1waLm98ArkFFV2G by sir@cmpwn.com
2020-09-18T17:15:47Z
0 likes, 0 repeats
@parisni @iptq for sure, already do
(DIR) Post #9zI24KSn64zen0Dsbw by sir@cmpwn.com
2020-09-18T17:16:55Z
0 likes, 0 repeats
@parisni @iptq we should be able to handle ~100,000 req/sec with a peak connection pool latencies of 0.5s based on our current designAnd I have some optimizations in mind which could improve on both of those numbers
(DIR) Post #9zICuMuQFSIuyTbHN2 by brown121407@fosstodon.org
2020-09-18T19:19:30Z
0 likes, 0 repeats
@lain @sir what everyday features does it lack? I found myself missing so few and unimportant things when on Sourcehut that I don't even remember them.
(DIR) Post #9zICuNANI943lx41Ee by lain@lain.com
2020-09-18T19:20:03.514442Z
0 likes, 0 repeats
@brown121407 @sir maybe i'll have to try it again!
(DIR) Post #9zIDAjjBB1PENX98GO by sir@cmpwn.com
2020-09-18T19:20:36Z
0 likes, 0 repeats
@brown121407 @lain he probably means pull requests because the lack of them is a thing naysayers often feel is an affront to their sensibilities
(DIR) Post #9zIDBATVjNupKl1V5c by duponin@udongein.xyz
2020-09-18T19:23:08.781889Z
0 likes, 0 repeats
@brown121407 @lain @sir probably emoji reaction and comment to commit to make fun of Rin (with kindness, obviously)
(DIR) Post #9zIDJ3jifWR6kdMqkC by brettgilio@mstdn.social
2020-09-18T19:23:12Z
0 likes, 0 repeats
@sir @lain @brown121407 they like to purposefully overgeneralize to make terrible and inconsistent retorts that dont make sense in any context.
(DIR) Post #9zIDUf0wPYQfYFxFuS by lain@lain.com
2020-09-18T19:26:40.232609Z
3 likes, 0 repeats
@brettgilio @sir @brown121407 guys. we run a proper open source project, with tons of contributors and lots of commits going on. we use gitlab and are very aware of many of the bad parts it has. still, it does give us features like an integrated CI, user class, a review system, github-style pull requests (yes, people are used to these by now). my point was (and is) that even if srht is good software (and afaict it is) you won't get many people to use it by telling everyone who wants some other feature 'you're holding it wrong, and it's because you're stupid'. the 'naysayer' comment above is again this exact attitude.
(DIR) Post #9zIDoumrTfSaGJ1kLA by brettgilio@mstdn.social
2020-09-18T19:27:50Z
0 likes, 0 repeats
@lain @brown121407 @sir nobody said anybody was stupid. We said that our technology has taken a backseat to principle.
(DIR) Post #9zIDouzygtx4uzADmi by lain@lain.com
2020-09-18T19:30:18.503997Z
0 likes, 0 repeats
@brettgilio @brown121407 @sir maybe it's just my interpretation but i do feel like a certain intellectual and moral deficiency is at least implied in those people who don't want to use git send-email.
(DIR) Post #9zIDpDbrUmx0dh1jKi by sir@cmpwn.com
2020-09-18T19:28:14Z
2 likes, 0 repeats
@lain @brown121407 @brettgilio I didn't say anyone was stupid for wanting these featuressr.ht provides most of what you mentioned here. Perhaps not with the same workflow, but that's a feature, not a bug.
(DIR) Post #9zIDsbiALIluG3ajJY by lain@lain.com
2020-09-18T19:30:59.992892Z
1 likes, 0 repeats
@sir @brown121407 @brettgilio that's fine really. but to me, not having the workflow that dozens of people are used to is not a feature. maybe for a fresh start things would be different.
(DIR) Post #9zIDtDfJEN47yCXz8a by sir@cmpwn.com
2020-09-18T19:29:01Z
0 likes, 0 repeats
@lain @brown121407 @brettgilio and you are being a naysayer right now fyi
(DIR) Post #9zIDtDqIZVr8WHglGa by lain@lain.com
2020-09-18T19:31:06.615029Z
0 likes, 0 repeats
@sir @brown121407 @brettgilio nay
(DIR) Post #9zIEHDWZPGDcTzu16O by sir@cmpwn.com
2020-09-18T19:31:32Z
1 likes, 0 repeats
@lain @brown121407 @brettgilio you will note that I haven't moved sway or wlroots from github to sourcehut for this very reason
(DIR) Post #9zIGDvBlJyR6ehj4i0 by shmibs@tomo.airen-no-jikken.icu
2020-09-18T19:57:14.688047Z
1 likes, 0 repeats
@lain @sir @brettgilio @brown121407 maybe it's picking nits, and haven't tried properly using before, but the web interface feels a little messy, is here's first impressionwithout contrast or framing, everything blends together a lot, text areas are a bit too wide to read comfortably, nav context is lost on tickets/mailing tabs, etc. mostly things that could be css-ed and not cause problems for text browsers. the html being a bit more structured, using semantic html5 stuff etc, could be nice for accessibility also, if that was something cared aboutdunno, am walnut gallery