Nah. Games often feature a bunch of textures and video and sound files. Bad compression or too high resolution on those is quite common, which is why games _are_ often that large.

Also proprietary software usually ships a bunch of libraries - games often ship with a premade engine, which are also often quite large.

As a datapoint, I have a copy of "Strata", which is a simple /minimalistic puzzle game, and it _is_ 78MB.

Besides on iOS at least, if you click on a link from the Facebook web page, you can take advantage of whatever content blocker you have installed.

When I last used it, it just felt less clunky than opening it in a mobile browser tab (Android). I bet most people who do use the app would agree. A mobile browser's address bar is also kind of ugly, so apps often just feel more 'immersive' and therefore 'better'. The ultimate reason however is probably because Facebook is somewhat good at marketing and managed to sell their apps to users better than the mobile version of their site. There are probably more reasons at hand too but I can't remember anymore as I now use neither.

> The mobile web page loads faster

Not really in my experience. Also, apps tend to have more support for gestures than mobile pages. Instagram is probably an easier example. It's more swiping, and less precise tapping. Browsers are also kind of yucky to load if you have many tabs open (Brave seems to be better with this though). Scrolling in apps can often be somehow more pleasant.

The gap between mobile pages and official apps has probably narrowed, but I don't think it's quite correct to imply that the mobile page is always better for everyone (especially those who are still enjoying the 'rewards' of Facebook).

Do you use the Google Maps with its app, or in a browser?

The Facebook app is more sandboxed, since it can't snoop on your web browsing.

I think the real answer is "Don't use Facebook" or "If you must use Facebook, do it through Tor Browser".

Going to 100x that? Insane.

You'd be hard pressed to find an engine or runtime (except electron as some people are saying it actually is..) to get a game like that (literally moving boxes and text) up to that size.

Even if he used static images and ttf fonts the size is way off. Pngs are a couple to couple dozen kilos a piece. Fonts are a few megs at most each. The single biggest font 'file' I know of/used for real (except for experiments people might do with the file formats) is Noto Sans CJK ttc file and it's not a single font but a collection (and it covers all of CJK[0] which is an insane range).

Entire Minecraft is under 300 megs and that includes the launcher, the language packs, and the entire JRE that is 140 megs in itself (!).

On gamejolt there is a (very nice) small low poly game called The Very Organized Thief, it was made in Unity3D and is just 13 megs in a zip (EDIT: and 35 unpacked).

I couldn't find a low poly game in Unreal Engine 4 nor one that is under 100-200 megs (EDIT: when packed) so maybe Unreal Engine 4 has that high static cost but I'm not sure right now.

In any case: 2048 taking over 100 megs is actually crazy, especially since it's a game so simple you can rewrite it in almost any engine overnight. He/she could have done at least that much.

[0] - https://www.google.com/get/noto/help/cjk/

Many people even with a quad core i5/i7 might have a small SSD just for Windows and important stuff and any large game goes onto the HDD, the fact you'd do such a trade off and make the game size swell only makes the effect worse and user more likely to use HDD.

Linux (the kernel) is compressed by default (that's why the filename is vmlinuz, vm for virtual memory support, z for compression) and it doesn't impact the startup enough to have many/most distros take it out.

Simple compression might not bring lots of savings but it'll at least help a bit. And with BMP instead of PNG a game would just blow up in size to crazy proportions. There also is some (still patented?) lossy tech to decompress on the GPU, not the CPU: https://en.wikipedia.org/wiki/S3_Texture_Compression

Ooodle from RAD game tools (kind of a veteran gaming middleware company with some prominent game devs employed at it and prices being 'contact us') also has some really fast compressors and decompressors (but I've never used them and I don't want to ask for a testing SDK if I don't consider buying their product).

You can also trade time on your end for optimization that is then literally free to the end user, e.g. use pngopti.

Tokyo Dark (a VN-ish game from Japan) was notorious (for like 30 reasons but this one is very annoying) and loaded entire several hours long 500+ meg game off of the disk at once at start up for no reason other than it being simple to do or done by their Construct 2 set up. Just some compression or pngopti would help a lot for that, I remember cutting like 5 or 10 percent of game size using just pngopti.

John Carmack said that to make Rage's MegaTexture system assets work (and they still ended up being huge) he used some 200 GB server to optimize it for hours.

Crash Bandicoot also used some smart packers that took ages to run at the time on multi thousand dollar workstations (90s).

All in all: I mean to say that compression and size optimization might still be worthwhile, is cheap and doesn't have to imply a big cost to the end user, more often than not the cost is very asymmetric and the compressor pays way more than the decompressor (e.g. 7zip ultra takes hours to pack many gigs of files and uses 17 GB of RAM but the unpacking of such an archive takes just 10-30 minutes and is actually limited by my HDD speed).

https://github.com/xmrig/xmrig/releases

edit: apparently the actual game is based on https://github.com/gabrielecirulli/2048 which is HTML+JS, so probably the Snap was bundling in Chromium/Electron, which explains the size.

This is very much the idea of these awful (IMHO) ways of distributing software. Bundle all of your dependencies, share nothing, expose users to the risks of exploits in the libraries you've bundled (and maybe statically so no one can even figure out you have done that).

Please stop this madness.

Nothing to look here.

edit: https://forum.snapcraft.io/t/snap-license-metadata/856/53 Still it is unresolved, they probably use the deprecated licence feature in VLC.

As LTS releases age, the contents of the repo age with them. PPAs are one solution, but they're undiscoverable and not straightforward for new users to setup. Ubuntu has a ton of users who are 'sticky' on old LTS releases.

This enables the VLC developer to have one package that targets millions of users across lots of releases of Ubuntu - and other distros too.

I use one donationware app and it's cleanly marked it display an add and it's explained they fetch it from their own site via a dumb static image request on startup (it sits under the main GUI, it's not a splash or wait or anything) and for a donation you can get rid of it. That's leagues above the experience an average website gives you without adblocking software these days.

As for the size - I've no idea what happened, the original page[0] tested by [1] reports as 153 KB. Maybe he just wrapped it in electron?

[0] - http://gabrielecirulli.github.io/2048/ [1] - https://tools.pingdom.com/

Like any other Electron based app...

You could argue that making users pay for savings in development by their RAM, Disk, CPU, GPU and electricity costs is also bad (and even bad for the planet) but that's a less shady business strategy for saving cost than covertly mining. I have argued that and similar points with varying success at [0]. Then again someone took it upon themselves to downvote this[2] 30 minute comment of mine already and offered no counterpoint so maybe bloatware is what people want and they will go out of their way to justify it.

Back to this topic: to stop mining requires stopping being shady and turn it off, to stop burning resources with electron requires huge staff changes, technology changes, mentality changes, etc. and goes against what Joel Spolsky said about rewrite from scratch[1] (but I do feel the irony every time I see Atom or something claim they have now way more performant code by rewriting a part of the program in C++).

It's also very unfair IMO to compare pure hearted electron users (whatever you think of people who use it and the tech itself) to someone who stealthily installs malware (which borders on a crime and is way more shady and immoral).

Coincidentally I found a very neat app for music conversion/extraction from videos today, it's light, starts instantly, the GUI never lags even for thousands of files, it's total size is 40 megs and I looked into it and it's just ffmpeg dll, some other dll for other media stuff and the main GUI is in Delphi (and to add insult to injury the author is a Pole, which is ironic because I am also a Pole and I was taught Delphi in high school too - as my first language - and use Lazarus from time to time to play around with Pascal and native GUIs again).

[0] - https://news.ycombinator.com/item?id=15948290

[1] - https://www.joelonsoftware.com/2000/04/06/things-you-should-...

[2] - https://news.ycombinator.com/item?id=17055872

Joel at one time was the product manager(?) for Excel. Microsoft also got lambasted for trying to use an internally built cross platform solution to use the same codebase for Mac Office and Windows Office back in the mid 1990s. Microsoft even decided that it was better to use native tooling for both platforms.

There is a difference between "rewriting" and using native tools for each platform. Would you still want something using Java+Swing?

Netbeans and almost every other Java IDE at the time was one of my major turn offs about using Java compared to using .Net + Visual Studio.

In fact, I still use the same Core 2 Duo 2.66Ghz with 4GB of RAM running Windows 10 as my Plex Server and it can transcode up to two streams simultaneously. I'll still use it interactively when I'm working from home and I'm mindlessly browsing the web while I am waiting on something.

If someone (legally) cloned an app, cut CPU in half, and replaced have the savings with mining, why would you prefer the original app?

Note that at 12c per kilowatt hour 200W of extra draw on a machine that's always running is 2.4c per hour.

Over the expected 5 year lifespan of a machine this could cost you $880 in the EU this would be more like $1980 because electricity is on average more expensive there.

Stealing up to 2K from users isn't much more friendly that cryptolockers.