Comment by pdpi
18 hours ago
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.
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.
> 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.
For many companies, IP isn’t allowed to leave environments controlled by the company, which employee laptops are not.
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.
2 replies →
Yes, zero latency typing in your local IDE on a laptop sounds like the dream.
In enterprise, we get shared servers with constant connection issues, performance problems, and full disks.
Alternatively we can use Windows VMs in Azure, with network attached storage where "git log" can take a full minute. And that's apparently the strategic solution.
Not to mention that in Azure 8 CPUs gets you four physical cores of a previous gen server CPU. To anyone working with 4 CPUs or 2 physical cores: good luck.