FYI VSCode's SSH Agent is a godsend for remote development - the "disadvantages" that Fly lists are part of its advantages. I've worked in several teams that have made extensive use of the extension, and it's never been an issue. You can restrict SSH access arbitrarily to ensure whatever security or access guardrails you need.
As a Linux user I've hated VSCode's ssh. There's lot of annoying things that make it harder to admin for. Like it doesn't pick up the MotD, preventing me from showing users important messages. I've found that it also doesn't reuse sessions (at least by default. TBF, neither does ssh) and I'll find that there's just dozens of open sessions over months from users. I literally had to write a script to boot people...
It would be one thing if the plugin was just a wrapper and people were still expected to know ssh but the plugin abstracts away all that and is intended to make it a "use VSCode on remote machine" tool. So it needs to do more than just handle creds, otherwise it creates a divergent experience while making people think it's just ssh
Ah, I see. Our admins typically understood that users were being given disk quotas precisely so that they could use that disk space, but that's probably not a universal stance.
Quotas mean "more than this is clearly too much" not "please use this space".
In good times nobody minds, but in bad times when you just can't extend the drive you have to tell people off. Part of the job of making sure the system can continue to work for what you need it, under _real_ constraints.
You may have to delete stuff, you may have to shut the server down to save power. You may have to limit clock speeds. It depends on the environment and "it really should work because it should be covered by next day on site warranty and you could download more ram" often doesn't apply.
Back in the day, because the architecture was shared memory and cooperative multitasking, this is how MacOS applications declared their memory constraints.
Apps had a (recommended and then user-configurable) "Minimum memory" and "Preferred memory." The app would not launch if the OS couldn't give it the minimum. It would then give the app up to the preferred amount, if available, exclusively... This was in the era before virtual memory and paging, so there was no easy way to share memory across an application boundary.
This mean that savvy users with high-resource tasks knew you had to launch your apps in a certain order to get the architecture into the configuration to do their work.
> Quotas mean "more than this is clearly too much" not "please use this space".
Ah, memories of Uni, back when storage was fairly expensive, where we had both hard and soft quotas. The soft quota would allow for temporary growth of build artefacts and things¹ but you would get stern emails if you were over your soft quota for 24 hours, and if you persisted without good reason³ your hard quota would be reduced so you effectively have no soft quota any more.
--------
[1] some machines had no local storage that the user could touch so putting them there was not always possible, some people on Windows machines had local storage but didn't have the relevant tools locally so were actually running things on the shared server(s)² instead of that just being a storage resource
[2] via telnet/rsh/rlogin: yes, I am that old… SSH was a thing by that point, though OpenSSH wasn't, and I was using it where available, but the use of older plain-text protocols was still far far more common
[3] it wasn't actually difficult to justify a quota extension for project work, in fact people enrolled on certain modules got higher quotas automatically
Yes, let's hope it doesn't get even more expensive. Around here we are purposely not upgrading hardware unless we have to, hoping to ride through the price increases. I'm sure lots of people are doing the same thing, which probably won't help much once prices start to come back down... assuming they do.
This is a fascinatingly "pets" approach to admin; it's been ages since I've been somewhere that used this approach. I've been in the "cattle fields" for decades now.
In my ecosystem, developers don't have time to glad-hand like this; if there are issues with DEV_NODE_CFG_1_29875, we might talk about it over Slack (because I'm the first one to know there's a problem as the end-user), and if we can't sort it out they'll give me some time to backup, blank the whole machine, and I get a brand-new image of DEV_NODE_CFG_1_29875.
I can't even tell you off the top of my head what territory the physical machine is running in or whether it's the only dev-node on that hardware.
(Broadly speaking, I think Microsoft is assuming cattle ecosystems; they're not openly-hostile to pets per se, but they have a strict ranking of the priorities because the "cattle ranches," as it were, bring in more money).
danielklnstein · · focus · HN ↗
FYI VSCode's SSH Agent is a godsend for remote development - the "disadvantages" that Fly lists are part of its advantages. I've worked in several teams that have made extensive use of the extension, and it's never been an issue. You can restrict SSH access arbitrarily to ensure whatever security or access guardrails you need.
godelski · · focus · HN ↗
It would be one thing if the plugin was just a wrapper and people were still expected to know ssh but the plugin abstracts away all that and is intended to make it a "use VSCode on remote machine" tool. So it needs to do more than just handle creds, otherwise it creates a divergent experience while making people think it's just ssh
Joker_vD · · focus · HN ↗
godelski · · focus · HN ↗
Joker_vD · · focus · HN ↗
literalAardvark · · focus · HN ↗
Quotas mean "more than this is clearly too much" not "please use this space".
In good times nobody minds, but in bad times when you just can't extend the drive you have to tell people off. Part of the job of making sure the system can continue to work for what you need it, under _real_ constraints.
You may have to delete stuff, you may have to shut the server down to save power. You may have to limit clock speeds. It depends on the environment and "it really should work because it should be covered by next day on site warranty and you could download more ram" often doesn't apply.
williamdclt · · focus · HN ↗
super tangential, but makes me think I never realised that "quota" can either be a lower or an upper bound depending on context
shadowgovt · · focus · HN ↗
Apps had a (recommended and then user-configurable) "Minimum memory" and "Preferred memory." The app would not launch if the OS couldn't give it the minimum. It would then give the app up to the preferred amount, if available, exclusively... This was in the era before virtual memory and paging, so there was no easy way to share memory across an application boundary.
This mean that savvy users with high-resource tasks knew you had to launch your apps in a certain order to get the architecture into the configuration to do their work.
dspillett · · focus · HN ↗
Ah, memories of Uni, back when storage was fairly expensive, where we had both hard and soft quotas. The soft quota would allow for temporary growth of build artefacts and things¹ but you would get stern emails if you were over your soft quota for 24 hours, and if you persisted without good reason³ your hard quota would be reduced so you effectively have no soft quota any more.
--------
[1] some machines had no local storage that the user could touch so putting them there was not always possible, some people on Windows machines had local storage but didn't have the relevant tools locally so were actually running things on the shared server(s)² instead of that just being a storage resource
[2] via telnet/rsh/rlogin: yes, I am that old… SSH was a thing by that point, though OpenSSH wasn't, and I was using it where available, but the use of older plain-text protocols was still far far more common
[3] it wasn't actually difficult to justify a quota extension for project work, in fact people enrolled on certain modules got higher quotas automatically
zie · · focus · HN ↗
Don't worry, disk got expensive again. Disks are usually at least 2X more expensive than a year ago currently. Sometimes 3X more.
dspillett · · focus · HN ↗
zie · · focus · HN ↗
wongarsu · · focus · HN ↗
HDD prices are a bit more reasonable. Mostly because they are so heavy. Still insane to where prices were just 12 months ago
throw0101a · · focus · HN ↗
Probably why both soft and hard limits were developed.
shadowgovt · · focus · HN ↗
In my ecosystem, developers don't have time to glad-hand like this; if there are issues with DEV_NODE_CFG_1_29875, we might talk about it over Slack (because I'm the first one to know there's a problem as the end-user), and if we can't sort it out they'll give me some time to backup, blank the whole machine, and I get a brand-new image of DEV_NODE_CFG_1_29875.
I can't even tell you off the top of my head what territory the physical machine is running in or whether it's the only dev-node on that hardware.
(Broadly speaking, I think Microsoft is assuming cattle ecosystems; they're not openly-hostile to pets per se, but they have a strict ranking of the priorities because the "cattle ranches," as it were, bring in more money).