Pay as you go is really going to make a difference

user5678 user5678 at 9012.sd
Mon Jan 13 11:54:19 UTC 2020


On Sunday, 12 January 2020 at 22:59:22 UTC, Arine wrote:
> On Sunday, 12 January 2020 at 20:29:59 UTC, aberba wrote:
>> https://tonsky.me/blog/disenchantment/
>
>
> Wow, this person is really uninformed. They know just enough 
> about something to make a naive comment but not enough to 
> understand *why* it is the way it is.
>
>> An Android system with no apps takes up almost 6 GB. Just 
>> think for a second about how obscenely HUGE that number is. 
>> What’s in there, HD movies? I guess it’s basically code: 
>> kernel, drivers. Some string and resources too, sure, but 
>> those can’t be big. So, how many drivers do you need for a 
>> phone?
>
> The onboard memory on an android device is generally hardwired 
> into the system. That means the 
> system/vendor/boot/dtbo/vbmeta/etc... partitions are going to 
> be a set size. So even if my system image is 1.4 GB and vendor 
> image is 500 mb. It'll still take up 6 GB if that's what was 
> allocated to that partition. The device I'm working on 
> currently has about 4 GB for the system partition and 1 GB for 
> the vendor partition.
>
> So about 1.4 GB for system image, the largest  folders are for 
> apps. The largest app is Webview totaling 108 MB (in app/). So 
> just the webview alone can take half the space of the rest of 
> the public apps. This is meant to be a minimal android build, 
> so I wouldn't doubt a lot of that space does end up being taken 
> up by pre-installed apps, and extra space for future updates.
>
> 12K	addon.d
> 225M	app
> 27M	bin
> 4.0K	build.prop
> 104K	compatibility_matrix.xml
> 5.9M	etc
> 20K	fake-libs
> 16K	fake-libs64
> 69M	fonts
> 217M	framework
> 149M	lib
> 222M	lib64
> 21M	media
> 233M	priv-app
> 8.0K	product
> 27M	usr
> 0	vendor
> 13M	xbin
>
>> Windows 95 was 30MB. Today we have web pages heavier than 
>> that! Windows 10 is 4GB, which is 133 times as big. But is it 
>> 133 times as superior? I mean, functionally they are basically 
>> the same. Yes, we have Cortana, but I doubt it takes 3970 MB. 
>> But whatever Windows 10 is, is Android really 150% of that?
>
> Not sure why he thinks things taking up more spaces means they 
> have to be better somehow? Developers have limited time, I'm 
> sure they could squeeze out 500+ MB or something, but how much 
> developer time would that take? Is it worth wasting the time to 
> minimize it that much when people have 4 TB hdds? When they can 
> download a 4 GB file in < 2 mins.
>
> That's what he isn't getting. Doing these things isn't free. It 
> takes development time to do all these things, development time 
> that thanks to the hardware we have today, allows for it to be 
> spent else where. Where it is more valuable. I remember using 
> Windows 95, it's garbage in comparison to Windows 10. Comparing 
> an OS based solely on it's file size, is just something someone 
> incompetent would do.
>
>> Modern text editors have higher latency than 42-year-old 
>> Emacs. Text editors! What can be simpler? On each keystroke, 
>> all you have to do is update a tiny rectangular region and 
>> modern text editors can’t do that in 16ms. It’s a lot of time. 
>> A LOT. A 3D game can fill the whole screen with hundreds of 
>> thousands (!!!) of polygons in the same 16ms and also process 
>> input, recalculate the world and dynamically load/unload 
>> resources. How come?
>
> I'll just assume he's talking about electron based editors 
> here. They are built ontop of a web browser so yah they are 
> going to be a bit more resource hungry. But if you take VS Code 
> as an example. It is extremely easy to customize. There's no 
> dozens of forks of it that modify little things to get certain 
> features. There's more quality extensions for VS Code that 
> integrate flawless, that aren't hacks than there are for Emacs, 
> even though VS Code hasn't existed for nearly as long. There's 
> a trade off for the ease of development and customizability. 
> The latency also isn't that bad, it is pretty bad in Atom but 
> that just shows the difference between the two.
>
> Then he compares that to games and GPU rendering, just ugh. 
> Maybe he didn't know it runs in a web browser, but he also goes 
> on a rant about how web browsers don't render fast enough for 
> him. Web browsers need to be secure, achieving performance a 
> long side that is difficult. He seems to be in the mind set 
> that security doesn't matter, or at the very least he probably 
> doesn't think about it, as it seems to be more often than it 
> should be. There's a reason why there's only so many web 
> browsers. Hell even Microsoft gave up and uses Chromium's 
> backend. Think about that, Microsoft, with a B.
>
> Then the whole, oh we went to the moon with these slow 
> computers. Yah going to the moon is pretty easy in comparison 
> to some computer problems. As someone put, when a politician 
> tried to make the same argument about going to the moon, it'd 
> be akin to walking on the surface of the sun.
>
> I could go on, this article is way too long and it's filled 
> with misconceptions, terribly awful comparisons, and just so 
> much more.

Nah, the author of the article is right. The web and its techs 
(js) are completely retarded. I've myself observed on top of the 
usual slowness, a regression, on several major sites, during the 
latest months.

About the part on keyboard latency. This is based on another blog 
post I've read a few years ago. 
(https://hexus.net/tech/news/peripherals/113648-modern-computer-complexity-heavy-impact-keyboard-latency/) and other stuff too.

The problem might be that you're so much into the web services 
that you don't even realize anymore how softs made in the classic 
way were much faster. But those softs failed to adapt to the web 
so developers have started to look elsewhere for a better 
interaction with the web.

At some point in the late 2000's compiled languages have lost. 
The article posted by the OP is fundamentally about that, if you 
read between the lines.


More information about the Digitalmars-d mailing list