Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Considering Sourcehut

postmarketos.org

Post reply on HN
Print view View original

51–60 of 81 posts

Re: Considering Sourcehut

#51

Post by sorrychuck »

olalonde wrote: post #25

I just can't get past how bad SourceHut's UI is. They really need to hire someone that knows some basic UI principles. Edit: As a commenter suggested, I will elaborate a little: I'm a big fan of minimalist and lightweight UIs, that's not my issue with SourceHut's design. My issue is the disregard for several established UI principles (balance, proportion, repetition, etc.). Some examples: - The login[0] and register[…

Agreed, the styling has put me off by feeling broken / unfinished. In particular too little and too inconsistent padding.

However reviewing now I’ll say that for whatever reason it seems things are much improved. Still not my personal favorite but significantly more clear.

Re: Considering Sourcehut

#52

Post by jraph »

joshxyz wrote: post #45
jraph wrote: post #8

Makes sense. SourceHut is probably perfect for Postmarket OS. Both have a strong taste for minimalism and free software. Choosing hosting provided by SourceHut instead of self hosting may also help fund SourceHut itself so that's good too. Go for it! I too am not really happy with GitLab.com. It requires contributors to fill a reCAPTCHA and I'm not a fan of it being open core. I chose Gitorious (and was moved to GitL…

wow gitlab must be truly evil for being proprietary

When I write GitLab.com, I'm referring to the service, not the software project. The service relies on reCAPTCHA. The project provides the feature but does not require it nor enable it by default.

I'm not going to say that GitLab is evil. I don't think it is. I don't see the world like this anyway. But yes, there are proprietary bits involved in Gitlab.com (and the service actually runs Gitlab EE afaik). What do you expect from me as a free software enthusiast? Close my eyes and suck it, or live to my principles, which is easy considering there are good open source forges that are also not based on an open core model?

As cool as GitLab is to the eyes of many people, I don't like making unnecessary exceptions.

Now, I would still be fine self-hosting GitLab CE. But from a technical perspective, Gitea is probably better than GitLab for me: it's lighter on resources and easier to maintain. I also like the UI better.

Re: Considering Sourcehut

#53

Post by gspr »

Tmpod wrote: post #32
gspr wrote: post #17

Earlier quoted context omitted.

> Why are so many of your great contributors so hostile to the only part of the Internet that is still truly decentralized? > Why do they hate store-and-forward, latency-tolerant networks? I do like email-based development. And I pay for Sourcehut. But I also understand why others don't like email-based interfaces. And I too sometimes get annoyed by Debian's BTS taking minutes to act on (email-based) changes to bug r…

> but oh man sometimes an instantaneous interface is important. That can indeed be a flow breaker, however, in my experience, it's not necessarily an email issue, but Debian's in this case, since sending stuff to lists.sr.ht is pretty snappy (like a couple of seconds after the client sends it). It isn't as fast and instantaneous as your typical web UI yet it's not a flow breaker either, imo, though YMMV.

But that's the point: the original poster pointed out the great value in store-and-forward, latency-tolerant systems like email. So while you may indeed be lucky and have low-latency interactions through email in certain situations, you've then added extra assumptions and requirements to the aforementioned latency-tolerant robust system. Wanting fast ("instant") response times from a system based on email seems like a folly.

Re: Considering Sourcehut

#54

Post by gspr »

beardicus wrote: post #47
olalonde wrote: post #25

I just can't get past how bad SourceHut's UI is. They really need to hire someone that knows some basic UI principles. Edit: As a commenter suggested, I will elaborate a little: I'm a big fan of minimalist and lightweight UIs, that's not my issue with SourceHut's design. My issue is the disregard for several established UI principles (balance, proportion, repetition, etc.). Some examples: - The login[0] and register[…

strong agree, though with the caveat that it's "bad" for my tastes and priorities, but is clearly ok for other folks. it feels all too common for folks to rage against bloaty interfaces (i agree, they're terrible!) but swing wildly back towards clunky browser-default randomness. you can have a consistent, polished interface without javascript and tons of images! one thing w/ sourcehut that i find adds confusion is th…

This is the one thing I, too, struggle with with sr.ht. I keep on using it, but I can't wrap my head around why this is supposed to be a good way to do it.

Re: Considering Sourcehut

#55

Post by emptyparadise »

Tmpod wrote: post #34
goodpoint wrote: post #33

Earlier quoted context omitted.

I love minimalistic javascript-free UIs and that sourcehut is fast (and under AGPL). Yet I find the layout in Sourcehut really confusing and not self-explanatory. Not having a bugtracker UI and having to jump around different FQDNs related to the same project is a usability killer for me. I don't expect forges to copy github. E.g. trac is very different but still has a rational and friendly layout. EDIT: I also like…

Yeah, the disconnect between sourcehut components isn't great, but AFAIK they are working on hub.sr.ht or smth like that, and also better integration between all of those services, precisely to fix that issue. I'm eager to see that implemented, because it will be a good step forward.

I don't even mind the separate component approach but I wish they would just have a single consistent navigation bar on all of them for switching between all the services for a project.

Re: Considering Sourcehut

#57

Post by dncornholio »

5e92cb50239222b wrote: post #46
dncornholio wrote: post #44

Earlier quoted context omitted.

This is always the problem with most of free software. They are so awkward to use. Meanwhile any criticism is very often met with getting downplayed.

> often met with getting downplayed Or maybe it's just a matter of taste? Personally I find many popular proprietary applications (including web "applications") as comfortable and enjoyable to use as walking on two hands backwards while blindfolded. Yet most people around me seem quite satisfied.

And these people end up building it them selfs and that's how we end up with 2 extremes instead of a common middle ground?

Re: Considering Sourcehut

#58

Post by joshxyz »

jraph wrote: post #52
joshxyz wrote: post #45

Earlier quoted context omitted.

wow gitlab must be truly evil for being proprietary

When I write GitLab.com, I'm referring to the service, not the software project. The service relies on reCAPTCHA. The project provides the feature but does not require it nor enable it by default. I'm not going to say that GitLab is evil. I don't think it is. I don't see the world like this anyway. But yes, there are proprietary bits involved in Gitlab.com (and the service actually runs Gitlab EE afaik). What do you…

on features that are useful for individual users but are only available enterprise-only, kinda makes sense. https://sso.tax/ for example lol

Re: Considering Sourcehut

#59

Post by Jasper_ »

cxr wrote: post #43
_ikke_ wrote: post #23

Earlier quoted context omitted.

The issue is most users do not have the infrastructure to let others pull directly from their repositories, hence centralized hosts became popular.

Well, no, that's putting the cart before the horse. Git was not designed for remote fetching from every menial contributor. Nothing was—it didn't make sense to.* The idea with git-pull is that it's for use among a set of frequent collaborators—so for a given repo you have a handful of remotes, if any. It was not intended that everyone would need "infrastructure to let others pull directly from their repositories". Th…

What are you talking about? git request-pull came far before GitHub existed, and that sends an email for a request & instructions to pull from a remote branch.

Re: Considering Sourcehut

#60

Post by ddevault »

emptyparadise wrote: post #55
Tmpod wrote: post #34

Earlier quoted context omitted.

Yeah, the disconnect between sourcehut components isn't great, but AFAIK they are working on hub.sr.ht or smth like that, and also better integration between all of those services, precisely to fix that issue. I'm eager to see that implemented, because it will be a good step forward.

I don't even mind the separate component approach but I wish they would just have a single consistent navigation bar on all of them for switching between all the services for a project.

We will be adding this soon, it's an acknowledged priority for the beta.
Post reply on HN