Slack should not eat 10 GB of RAM, but if you make bad faith comparisons like that, you're worse than actual luddites. Luddites had good points on labor versus capital, you're just pointlessly whining
-
-
Show this thread
-
I'm sorry, my patience for lack of even a back-of-the-envelope validation of tech nostalgia rants runs very low these days
Show this thread
End of conversation
New conversation -
-
-
Well, I was talking about on-screen keyboard, it doesn’t need smooth scrolling, and it requires 150 Mb _on disk_. I can, too, name things that weight 70 Mb, what does it have to do with anything?
-
I guess this was confusingly phrased, so let's try again. memory footprint of a modern webpage on the order of 100 MB is OK because that's how browsers achieve low input latency. wire footprint of same on the order of 10 MB of JS is OK because the offline applications they…
-
replace were often much larger, even if you add the size of the browser itself. flash footprint of a modern Android app on the order of 100 MB isn't OK, but this is a problem inherent to the way Android evolved as an open platform and not computing in general.
-
you're complaining about bloat in general, but there's no such thing. some of it only appears to be bloat, and some of it has to be dissected on a case by case basis to get any useful insight. classifying programs by bloat is like classifying cats by number of toes.
End of conversation
New conversation -
-
-
I don't think the 4K triple buffered framebuffer is stored somewhere at install time, so that's 70mb you can't claim.
-
talking about RAM footprint. if we're talking about JS sizes on the order of 10 MB, well, that compares very favorably to the size of the offline app it replaces, which is usually on the order of 100-1000 MB (e.g.: Office, Outlook)
-
you may have a point but that article was actually talking about the disk space footprint of OSes and apps. If anything, using only web-based apps should actually reduce the disk space but he noticed the reverse effect.
-
Firefox OS was quite compact; Android apps drag a ton of stuff in apks these days because every older version of Android they support comes with compatibility libraries for that specific version. This is an issue with the design of Android but not modern computing in general
-
are you saying Android isn’t modern or everything else is super-efficient and only Android is a bad example?
-
neither
End of conversation
New conversation -
-
-
this article says "Linux kills random processes by design. And yet it’s the most popular server-side OS." which i assume is talking about the OOM-killer but makes me imagine, like, linux just randomly killing processes for no reason
-
you can just turn off overcommit if you want. actually understanding that doesn't make for a good rant though
-
yeah, but then fork stops to work, and there’re lots of things depending of fork. Actually understanding “there’s an option but nobody uses it” doesn’t make for a good argument though
-
I use it and it works, tell me where I'm wrong
-
So you are simply assuming *he* (implying *everyone* using linux kernel) can turn it off because it works for *you*. Are you suggesting this mechanism is actually not needed in the kernel as everyone should have it turned off?
-
nope. he claimed that setting vm.overcommit_memory=2 inherently breaks fork, which is obviously false, as anyone can verify by, for example, doing that on one of their machines and observing the results
-
so there’s no problems with fork and vm.overcommit_memory=2? Why isn’t it the default or even recommended setting then?
-
there are obviously no problems with fork and without overcommit because Linux is the only Unix-like that has overcommit enabled by default in the first place, yes.
- 3 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.