> When someone says "It is possible to use RAM inefficiently" you present a counter argument with an example of efficient use and by that you are trying to abolish the actual irrevocable fact that inefficient RAM usage is possible. But this hasn't really been an problem in years. I assume you're referring to disk fragmentation, which occurs on hard drives it matters there because hard drives are not random-access, and having related files in completely different physical locations or, worse, having one file split into multiple physical locations means it takes longer to read. RAM doesn't "fragment" in any meaningful way. In fact that sounds like what I would expect someone to do to be more "efficient" with their RAM use. > If you constantly allocate and deallocate huge amounts of memory this is an overhead. In any case, that's the point: if you can afford RAM use (and yes, you can afford to have a program use hundreds of MB if you have 4, 8, or even 16 GB total), then it is always beneficial. Thankfully, Linux makes use of that RAM for disk caching while it waits to allocate it to a program, so it's not a total loss. We of course don't live in a perfect world, so some inefficiency (i.e. In a perfect world, the programs you're running would use every byte of RAM available and then release it to new programs as they launch. The point is that if you can spare RAM, ideally, you should be using all of it. There's a difference between using 2GB right now and using 2GB ever. Yes, but if you pay more attention to the context of what I was saying, that would be included under the umbrella of "use". > Starting a new program requires free memory. It is so promising a platform that I'm wishfully sure someone will pick it up and continue its development. Midori itself is already a very good compromise (functionality vs resource consumption) and would probably have been better than qupzilla, if only it was not orphaned for years. I gather that it is somewhat on par with midori. I hope it won't.Īlso there is netsurf but I haven't tried is as yet. Things may get out of hand and Qupzilla may become just another Konqueror (from KDE suit dependencies perspective). Actually in Debian, kwallet was first added as hard dependency to qupzilla, only recently reduced to "recommends" (which still translates into hard dependency with Debian's default apt settings). The author specifically states that "there will be no hard dependencies on KDE libraries" but already there are efforts for kwallet integration. One drawback (from my POW) is that it is being integrated into KDE. WebKit based, not much plugins but essential ones are there, is fairly compatible (better than Midori in my experience), fairly lightweight (memory footprint approximately half of Firefox and twice of Midori or so)
0 Comments
Leave a Reply. |