zlacker

>>xpe+(OP)
For example, memory leak investigation is currently spread across discussions, x/twitter and discord https://x.com/mitchellh/status/2004938171038277708 https://x.com/alxfazio/status/2004841392645050601 https://github.com/ghostty-org/ghostty/discussions/10114 https://github.com/ghostty-org/ghostty/discussions/9962

but has not graduated to issue worthy status

>>Maxiou+Yb
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.

>>quantu+Jc
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.

>>favfla+Uf
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 DAW with a bazillion plugins and samples, anything involving 4k video are all workloads that would struggle running on such a small RAM allowance.

>>pdpi+Nh
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.

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

>>sumant+2C
Current job used to let us run containers locally, but they decided to wrap initially docker, and then podman with "helper" scripts. These broke regularly, and became too much overhead to maintain so we are mandated to do local dev but access a dev k8 cluster to perform any level of testing that is more than unit and requires a db.

A really shame as running local docker/podman for postges was fine when you just ran the commands.

>>happym+uH
I find this quite surprising! What benefit does your org accrue by mandating that the db instance used for testing is centralised? Where I am, the tests simply assume that there’s a database available on a certain port. docker-compose.yml makes it easy to spin this up for those so inclined. At that stage it’s immaterial whether it’s running natively, or in docker, or forwarded from somewhere else. Our tests stump up all the data they need and tear down the db afterwards. In contrast, I imagine that a dev k8s cluster requires some management and would be a single point of failure.