Comment by bArray | Hacker News Reader

Comment by bArray | Hacker News Reader

Parent Full thread

> I've long observed that almost everything we are doing with

> our GHz computers, we were doing previously with old MHz

> systems.

I do also, but then I do have to pinch myself and remember some of the cutting edge software that really does make use of the hardware - i.e. games, video editing, neural networks, etc. I know we could already do these things on lesser machines, but there is no doubt that the level of which they are currently done could not be replicated on a lesser machine. And also remember the efficiency of systems such as web servers, todays average usage would be a DoS attack of the past.

I do look in disappointment though at text editors, window managers, file viewers, etc - that despite having much more computing power, offer not many more features but still eat tonnes of resources.

I'm currently (slowly) working on a Window Manger for X11 which tries to bring back some of these ideas but for modern devices: https://github.com/danielbarry/oakwm/ It's built on top of wm2 (which itself has roots going back to Bell Labs plan9). A lot of the work is in ripping out the unnecessary features and making it touch friendly. The idea is to run it on the PineTab Linux tablet.

I'd like a browser that is just a nice browser. It should fit easily into a few 10s MB and start instantly. It wouldn't waste 100s of MB on implementing dangerous/pointless/wasteful javascript APIs, like battery state or physical screen APIs; it wouldn't support (literally) 4300 options; wouldn't save 200 MB of config data; and wouldn't load many MB of data just to start and display a blank page!

Dillo/NetSurf may be of interest to you. They fit the size requirement as well as the "lack of JS" requirement (i.e. no JS support at all). "appsites" will definitely not work in them, but the document-oriented web and things like HN are fine.

I've used Dillo, but unfortunately most web pages are seriously malformed. Would be nice if it was possible to get some better CSS support.

I would like to see better JS support, but the scope of JS is simply insane for such a small browser. It's unfortunate much of the web is completely unusable without running JS. Perhaps it's possible to first run the page through a larger browser engine and then send the processed content to the small browser (such as Dillo), that would massively widen the scope of what it could display.

Use dillo from HG, it has better CSS support.

>But the scope of JS is simply insane for such a small browser.

Edbrowse has JS support thanks to duktape.

> Use dillo from HG, it has better CSS support.

Here? https://hg.dillo.org/dillo/

Seems to be still pretty old...

> Edbrowse has JS support thanks to duktape.

Huh, very interesting: https://duktape.org/

I initially assumed by ducktape you meant "barely held together"!

For the record, chrome on android is ~60MB, less than half the size of desktop chrome (~150MB). Android chrome supports the same set of javascript APIs. Clearly that isn't the whole picture.

I'm preeettty sure that's just because it's relying on the separate WebView app, using WebView is also how it's possible for people to make sub-megabyte android browsers, such as [Naked Browser](https://play.google.com/store/apps/details?id=com.fevdev.nak...) and [Via](https://play.google.com/store/apps/details?id=mark.via.gp&hl...)

*correction, according to https://developer.chrome.com/multidevice/webview/overview they are still separate, it references android L dev preview so not the latest source tho...

Actually, you can select which Chrome to use for the Webview in Android developer settings if you have Installed multiple versions of Chrome. Chrome stands on its own.

I measured Trichrome, which is the separate APK where the actual rendering engine is stored.

So Chrome for Android is 10MB larger than the entirety of Damn Small Linux, which includes a desktop environment with three web browsers (firefox, dillo and netrik).

While 60MB is still humongous, it does make sense that Google would at least care slightly on Android, as the majority of the Android market are low-to-mid-tier smartphones with reasonable performance instead of the "desktop-in-a-pocket" that are the current flagship phones.

But while they care slightly on Android, they don't care at all on desktops.

Remember kids: Large binaries are slow binaries.

Firefox on my mac is over 200MB. Is it smaller on Damn Small Linux?

And yes, there is clearly only an incentive to care on Android. The automated tooling to track Chrome binary size only works on the Android build.

>Large binaries are slow binaries.

False. Loop unrolling is always faster.

> False. Loop unrolling is always faster.

Blatantly false, which is why heuristics decide when to unroll.

Large code trashes instruction caches, and cache misses are very expensive. More code, more misses.

For very small loops, the unroll can pay off, but these are often too small to have significant size detriment.

Depends largely on the state of code caches, microcode and bus structure. Loop unrolling can be the worst thing you can do, on some architectures.

See, the hardware folks have listened in on the compiler people and their problems. They've done things like identify loops and rewritten them in microcode for optimization. If a short loop can fit entirely within the CPU code buffer, speed goes way up. Unroll the loop and blow the CPU code buffer, defeat the optimization and lose all that.

what you want isn't possible with the web being like MTV and moving far beyond it's original intention. The best you can get is get one of the small browsers and live with broken pages. Some people do just that. I think you should be think in terms of relativity though. Think about how much a "10 MB" only browser took up in main memory back in the day.

> I think you should be think in terms of relativity though.

> Think about how much a "10 MB" only browser took up in main

> memory back in the day.

This is exactly the point, software has swelled to use the resources available to it, so with each new iteration your machine gets faster but what it runs gets slower. It doesn't feel like this is something we should settle for.

Reply on news.ycombinator.com