That's plenty, especially for stuff like VPN clients.
Many of the protocols you'll be talking were created when computers had maybe 32MB of RAM or less, and you wanted to do more on them than merely connect to a VPN.
Lots of network hardware still in use nowadays doesn't have much more RAM than that either.
Even now, after twenty years of continued development, an openvpn client with all of its shiny new features enabled only uses about 6MB-7MB on my computer.
I know you mean it in jest, but language choice is far more than 'just' knowledge.
In see them young engineers bringing their new fancy stuff, and of course hitting walls everywhere, walls that we (old farts) sweated buckets to handle on our old. Dependency management (not only the libs, packages, but also the underlings OS, or libc, or even ISA...) and upgrade mills, training costs all over, coding standards to draw up, peer review tools and practices to upgrade, interfacing options with other projects to normalize, perf practices to upgrade... I'm forgetting many, and I have this email ready for every new language or tech, with all the hurdles to clear (and the post-mortem costs of clearing them in the past). Do the work, show your org and peers you thought about it seriously and how much we'll win.
If then the juice is worth the squeeze, by all means, let's go. It happens, a lot, but it can't be an individual choice for the whole org, or 'it's just a language'.
Indeed, however if Apple platforms are a deployment target, the least I would expect from any technical architect would be some kind of Objective-C or Swift knowledge.
This post is one good example of the implications of targeting platforms with languages outside of the ones provided in the SDK.
However as you say that is a lesson most young engineers have to go through, I also went through it.
In the end, it turned out to be more of a challenge than a problem, and resulted in improving the Go toolchain for everyone - bringing Go closer to being universally viable for this type of work.
Interesting journey, and a solution that benefits the broader community, not just the authors. It's a win-win in my book.
Just like Facebook betting in PHP ended up with Hippo and Hack.
Yet Facebook has learned it wasn't the best way of spending resources and nowadays most of their backend infrastructure is using C++, Java and whatever.
If you've been on the internet for a while, you've probably heard that iOS devices have far less memory than their Android counterparts. The main reason this works without problems is that the OS team is very, very conservative with letting people use memory. That this works is a testament to iOS's strategy of scaling up from the bottom rather than just throwing resources at a technical problem.
Fun anecdote. I'm in a middle of writing an ML app for android that uses ncnn on top of Vulkan. In that app I need to decide how big chunks of work the model will handle at a time. When ncnn on Vulkan is asked for memory available, on a desktop platform it dutifully let's you know how much vram your GPU has. On android the answer always seems to be 3.5GB. 3.5GB of VRAM on a smartphone? No way. Perhaps it is a quirk of all the hw I tested on so far or a bug. In fact the hardware GPU shares system memory, but I highly doubt I could actually use 3.5GB.
Yes, I did. Unfortunately it appears to just return a hardcoded number on Android. So I can't do much with this without knowing some vulkan API I could use. Perhaps if this becomes a real issue I'll spend more time on it and I'll find one.
The ml framework I use (ncnn) uses vulkan beneath.
True, however and without wanting to steel this thread, there is one good thing about Google's strategy, it shows a glimpse of how Longhorn could have been like as managed OS, if the teams actually worked together instead of WinDev defending their feud and redoing the whole stuff in COM, and now we are stuck with it.
So in some sense, it is the kind of strategy that is required when needed to prove a point instead of trying to convince others just with words, which is always a big pain point when trying to talk about better approaches to secure software development.
Because Apple went to use that API and hit that restriction themselves for the first time when they shipped Apple Private Relay and found it was too tight.
I was disappointed with that ending myself. Someone has to apply pressure to keep bloat under control. That pressure would be most effective from an entity as powerful as Apple. The modest specs of the iPhone itself used to provide that pressure, but now of course they have to keep selling next year's more capable model.
Because those were simpler operating systems and there were tight memory limitations. The industry can still do it if needed.
For an iPhone 12 (which shipped with iOS 14) just the 2 framebuffers for a double buffered display will take up the 15 MiB. Operating systems that are "significantly less than" 15 MiB would not be suitable to run a modern personal computing device.
Why is/was this comment greyed out while it is a good example of complex OSs which in their time were criticised for being heavy while being able to run in the L3 cache of modern CPUs?
Layer upon layer upon yet another layer of abstraction have made it so nobody sees the turtles the whole thing rests on...
Many of the protocols you'll be talking were created when computers had maybe 32MB of RAM or less, and you wanted to do more on them than merely connect to a VPN.
Lots of network hardware still in use nowadays doesn't have much more RAM than that either.
Even now, after twenty years of continued development, an openvpn client with all of its shiny new features enabled only uses about 6MB-7MB on my computer.