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

141–150 of 320 posts

Re: Why users cannot create Issues directly

#141

Post by xlii »

mitchellh wrote: post #59
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.

Note that this is an active discussion where we're trying to get to a point of clarity where we can promote to an issue (when it is actionable). The discussion is open and this is the system working as intended! I want to clarify though that there isn't a known widespread "memory leak issue." You didn't say "widespread", but just in case that is taken by anyone else. :) To clarify, there are a few challenges here: 1.…

I have a one bit that might be useful that I learned from debugging/optimizing Emacs.

macOS' Instruments tool only checks for leaks when it can track allocations and it is limited to ~256 stack depth. For recursive calls or very deep stacks (Emacs) some allocations aren't tracked and only after setting malloc history flags [0] I started seeing some results (and leaks).

Another place I'm investigating (for Emacs) is that AppKit lifecycle doesn't actually align with Emacs lifecycle and so leaks are happening on the AppKit and that has ZERO to do with application. Seems that problem manifests mostly on a high end specs (multiple HiDPI displays with high variable refresh rate, powerful chip etc.)

Probably nothing you haven't investigated yet, but it is similar to the ghost (pun intended) I've been looking for.

[0]: https://developer.apple.com/library/archive/documentation/Pe...

Re: Why users cannot create Issues directly

#142

Post by nkrisc »

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.

You asked if there is a justification and then in the same post justified why you need it.

Re: Why users cannot create Issues directly

#143

Post by mr_toad »

sumanthvepa wrote: post #88
gizmo686 wrote: post #35

Earlier quoted context omitted.

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.

Interesting. I required all my devs to use local VMs for development. We've saved a fair bit on cloud costs.

> Interesting. I required all my devs to use local VMs for development.

It doesn’t work when you’re developing on a large database, since it won’t fit. Database (and data warehouse) development has been held back from modern practices just for this reason.

Re: Why users cannot create Issues directly

#144

Post by arccy »

WhyNotHugo wrote: post #132

Personally, I find the distinction between “issues” and “discussions” annoying. For one, it duplicates the efforts in checking for prior reports. I might try 5–6 sets of keywords, but now I have to do so for 2 separate trackers. Tickets cannot be moved between trackers, so instead folks resort to duplicating it and moving discussions… which is entirely opaque if you’re following up via email: you won’t get any more n…

behold the best way to search github issues. Using Google or whatever decent search engine:

    site:https://github.com/org/repo key words

Re: Why users cannot create Issues directly

#147

Post by skobes »

mitchellh wrote: post #59
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.

Note that this is an active discussion where we're trying to get to a point of clarity where we can promote to an issue (when it is actionable). The discussion is open and this is the system working as intended! I want to clarify though that there isn't a known widespread "memory leak issue." You didn't say "widespread", but just in case that is taken by anyone else. :) To clarify, there are a few challenges here: 1.…

This illustrates the difficulty of maintaining a separation between bugs and discussions:

> To be clear, I 100% believe that there is some kind of leak affecting some specific configuration of users

In this case it seems you believe a bug exists, but it isn't sufficiently well-understood and actionable to graduate to the bug tracker.

But the threshold of well-understood and actionable is fuzzy and subjective. Most bugs, in my experience, start with some amount of investigative work, and are actionable in the sense that some concrete steps would further the investigation, but full understanding is not achieved until very late in the game, around the time I am prototyping a fix.

Similarly the line between bug and feature request is often unclear. If the product breaks in specific configuration X, is it a bug, or a request to add support for configuration X?

I find it easier to have a single place for issue discussion at all stages of understanding or actionability, so that we don't have to worry about distinctions like this that feel a bit arbitrary.

Re: Why users cannot create Issues directly

#149

Post by asdfaoeu »

codeflo wrote: post #124
throwaway81523 wrote: post #104

Earlier quoted context omitted.

The trouble here is that github issues is crap. Most bug trackers have ways to triage submissions. When a rando submits something, it has status "unconfirmed". Developers can then recategorize it, delete it, mark it as invalid, confirm that it's a real bug and mark it "confirmed", etc. Github issues is mostly a discussion system that was so inadequate that they supplemented it with another discussion system.

> Most bug trackers have ways to triage submissions. When a rando submits something, it has status "unconfirmed". Developers can then recategorize it, delete it, mark it as invalid, confirm that it's a real bug and mark it "confirmed", etc. As far as I'm aware, most large open GitHub projects use tags for that kind of classification. Would you consider that too clunky?

This still puts the onus on the developers to categorise the issues which I'm guessing they don't want to do.

Re: Why users cannot create Issues directly

#150

Post by wongarsu »

sumanthvepa wrote: post #88
gizmo686 wrote: post #35

Earlier quoted context omitted.

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.

Interesting. I required all my devs to use local VMs for development. We've saved a fair bit on cloud costs.

> We've saved a fair bit on cloud costs

our company just went with the "server in the basement" approach, with every employee having a user account (no VM or docker separation, just normal file permissions). Sure, sounds like the 80s, but it works rearly well. Remote access with wireguard, uptime similar or better than cloud, sharing the same beefy CPUs works well and gives good utilization. Running jobs that need hundreds of GB of RAM isn't an issue as long as you respect other's needs too dont hog the RAM all day. And in amortized costs per employee its dirt cheap. I only wish we had more GPUs.

Post reply on HN