Hacker News Reader

Comment by navtoj | Hacker News Reader

> While we were busy fixing the linker to save 1MB, iOS 15 launched and quietly gave us 35MB more.

why didn't the ios team do this before? 15 MB seems very low for network extensions

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.

Their problem was using Go in first place, but since they didn't want to add a language to their knowledge pool, they went on with this "solution".

And we all know how fat Go binaries tend to be.

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'.

Sorry for the Sunday rant...

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.

> 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)

I would love for you to share this. (even if it's not english)

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.

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.

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.

Considering this is Android, perhaps you can find the code responsible for returning this value?

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.

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.

Can you substantiate this?

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.

Our industry was once capable of building entire operating systems that ran in significantly less than that.

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.

SGI Irix and NeXTSTEP, simpler operating systems...

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...

A normal icon / avatar today is often recommended to be 512x512 pixels = 262 144 pixels

Back in those days a screen was often 640x480 = 307 200 pixels

An iPhone 12 Mini has a 1080×2340 screen = 2 527 200 pixels = over 8 times the size of those old screens

Today's OS:es work with much much larger datasets overall, not just in graphics but elsewhere as well, and are optimized for that

But if they use that additional quota, doesn't that break compatibility with older devices?

Reply on news.ycombinator.com