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

Why users cannot create Issues directly

github.com

Post reply on HN
Print view View original

31–40 of 320 posts

Re: Why users cannot create Issues directly

#31

Post by transcriptase »

typeofhuman wrote: post #27
tynorf wrote: post #25

Earlier quoted context omitted.

Chrome on my work laptop sits around 20-30GB all day every day.

I wonder if having less RAM would compel you to read, commit to long term memory, and then close those 80 tabs you have open.

I wonder if a good public flogging would compel chrome and web devs to have 80 tabs take up far less than a gigabyte of memory like they should in a world where optimization wasn’t wholesale abandoned under the assumption that hardware improvements would compensate for their laziness and incompetence.

Re: Why users cannot create Issues directly

#32

Post by pdpi »

typeofhuman wrote: post #27
tynorf wrote: post #25

Earlier quoted context omitted.

Chrome on my work laptop sits around 20-30GB all day every day.

I wonder if having less RAM would compel you to read, commit to long term memory, and then close those 80 tabs you have open.

If I'm doing work than involves three different libraries, I'm not reading and committing to memory the whole documentation for each of those libraries. I might well have a few tabs with some of those libraries' source files too. I can easily end up with tens of tabs open as a form of breadcrumb trail for an issue I'm tracking down.

Then there's all the basic stuff — email and calendar are tabs in my browser, not standalone applications. Ditto the the ticket I'm working on.

I think the real issue is that browsers need to some lightweight "sleep" mechanism that sits somewhere between a live tab and just keeping the source in cache.

Re: Why users cannot create Issues directly

#33

Post by afiori »

favflam wrote: post #24
quantummagic wrote: post #8

Earlier quoted context omitted.

That's a shame to hear. I had to give up on Ghostty because of its memory leak issue. Granted, it was on an 8GB system, but that should be enough to run a terminal without memory exhaustion a few times a week. Foot has been rock solid, even though it lacks some of Ghostty's niceties.

btw, is it me or is there any justification for anyone including a developer to run more than 8GB of RAM for a laptop? I don't see functionality as having changed in the last 15 years. For me, only Rust compilation necessitates more RAM. But, I assume devs just do RAM heavy dev work on a server over ssh.

Browser + 2 vscode + 4 docker container + MS Teams + postman + MongoDB Compass

Sure it is bloated, but it is the stack we have for local development

Re: Why users cannot create Issues directly

#34

Post by jonahx »

cortesoft wrote: post #12

Is this fundamentally different than just using tags on issues to separate ready to work on things from initial user submissions?

I feel like "technically, no" but "practically, yes".

Somehow the distinction of just adding a tag / using filters doesn't communicate the cultural/process distinction in the same way.

Re: Why users cannot create Issues directly

#35

Post by gizmo686 »

pdpi wrote: post #30
favflam wrote: post #24

Earlier quoted context omitted.

btw, is it me or is there any justification for anyone including a developer to run more than 8GB of RAM for a laptop? I don't see functionality as having changed in the last 15 years. For me, only Rust compilation necessitates more RAM. But, I assume devs just do RAM heavy dev work on a server over ssh.

There's all the usual "$APPLICATION is a memory hog" complaints, for one. In the SWE world, dev servers are a luxury that you don't get in most companies, and most people use their laptops as workstations. Depending on your workflow, you might well have a bunch of VMs/containers running. Even outside of SWE world, people have plenty of use for more than 8GiB of RAM. Large Photoshop documents with loads of layers, a D…

This depends on industry. Around here, working locally on laptop is a luxury, and most devs are required to treat their laptop like a thin client.

Of course, being developer laptops, they all come with 16 gigs of RAM. In contrast, the remote VMs where we do all of the actual work are limited to 4GiB unless we get manager and IT approval for more.

Re: Why users cannot create Issues directly

#36

Post by Groxx »

Hmm. I like it.

When I have a clear "Issue" which I've already researched, it's a bit of friction, but it doesn't seem like any more work to dump exactly the same text into a Discussion... and yea. Issues becoming a dumping ground is a real issue. This seems like a reasonable strategy / experiment.

Re: Why users cannot create Issues directly

#37

Post by gizmo686 »

tynorf wrote: post #25
favflam wrote: post #24

Earlier quoted context omitted.

btw, is it me or is there any justification for anyone including a developer to run more than 8GB of RAM for a laptop? I don't see functionality as having changed in the last 15 years. For me, only Rust compilation necessitates more RAM. But, I assume devs just do RAM heavy dev work on a server over ssh.

Chrome on my work laptop sits around 20-30GB all day every day.

How much would it take up if there was less RAM available. A web browser with a bunch of tabs open but not active seems like the type of system that can increase RAM usage by caching, and decrease it by swapping (either logically at the application level, or letting the OS actually swap)

Re: Why users cannot create Issues directly

#38

Post by voxl »

eviks wrote: post #10

> This pattern makes it easier for maintainers or contributors to find issues to work on since every issue is ready to be worked on. How is this not trivially solved via a "ready-to-be-worked-on" tag?

How is it not trivially solved by a discussion section? Why is your solution better for someone else's work flow? Why do you feel like you get to impose your way of doing work on an open source project?

Re: Why users cannot create Issues directly

#39

Post by gizmo686 »

I have never worked on projects that give non members write access to our bug tracker.

This includes both our open source project not giving the public access. And our entirely closed source internal projects not giving other developers within the company write access.

Re: Why users cannot create Issues directly

#40

Post by eviks »

voxl wrote: post #38
eviks wrote: post #10

> This pattern makes it easier for maintainers or contributors to find issues to work on since every issue is ready to be worked on. How is this not trivially solved via a "ready-to-be-worked-on" tag?

How is it not trivially solved by a discussion section? Why is your solution better for someone else's work flow? Why do you feel like you get to impose your way of doing work on an open source project?

Why do you feel like it's ok to make up nonsense about imposing? How can I impose anything on that project? Why break the expected/established workflow of users if the explanation doesn't work? Why are you asking 3 questions without answering 1?
Post reply on HN