Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

200 MB RAM FreeBSD desktop

vermaden.wordpress.com

Post reply on HN
Print view View original

151–160 of 223 posts

Re: 200 MB RAM FreeBSD desktop

#151

Post by FrostViper8 »

snvzz wrote: post #144
FrostViper8 wrote: post #111

Earlier quoted context omitted.

Lunduke is a grifter and just generally a bit of an idiot. e.g. I remember he once claimed Google was censoring him when he was de-listed from search, this was way back in 2009. His site had a malicious iframe because the PHP CMS he was using had been compromised. His politics are kinda irrelevant to me. There are people who are Agorist/Libertarian/Conservative tech influencers online that do decent and informative c…

>Lunduke is a grifter... And somehow you care so much you've created this account just to attack him. I'd suggest going out for a walk.

Yes. I created the account because someone asked what the problem was with Lunduke and I had something to say. I've been aware of Lunduke for quite a while and he has always come off a clown.

The fact is that hasn't actually given much to the community and has been a drama, pretty much since his appearance in Linux land. People used to dislike him then and wanted him gone and this was well before the current culture war nonsense that is often seen on YouTube, Twitter and backwaters like Rumble.

> I'd suggest going out for a walk.

I go out for an hour walk in the countryside every lunch time. I am not sure what my exercise routine has got to do with criticising a long time troll and grifter.

Re: 200 MB RAM FreeBSD desktop

#152

Post by lostmsu »

zozbot234 wrote: post #150
lostmsu wrote: post #145

Just to remind people here: a single uncompressed "4k" picture is 33MB. Have your compositor hold 10 of them and you get 330MB just for the window images. Across multiple monitors my desktop is 6400x2160, which at 32 bits comes to 55MB. Considering memory is slow and GPU compute these days is cheap maybe it would make sense to relayout and rerender things each frame directly into screen buffer instead of keeping the…

You need window surface buffers in order to do seamless compositing, scaling etc. It's quite technically possible to achieve pixel-perfect 2D rendering with GPU-side compute, but in many ways it's still an open problem.

Scaling is for legacy apps, right? Modern apps should get the area to render and the desired pixel density.

Not sure what you mean specifically by "need" in "need ... to do compositing". Compositing is just a way (e.g. rerender only on changes, cache results) of running a desktop environment. Strictly speaking you don't need compositing, you can just use immediate mode across the DE and apps.

The tradeoff of course is that if an app is lagging you get a blank rectangle instead of a frozen picture. Well not quite 0 or 1. You can cache lowres and/or compressed frozen picture periodically to improve UX.

Re: 200 MB RAM FreeBSD desktop

#154

Post by alyandon »

ValdikSS wrote: post #125
alyandon wrote: post #123

Earlier quoted context omitted.

It's the web browser and electron based apps that are the primary consumers of ram on my desktops with the DE and OS ram usage being minimal by comparison. I have an ancient laptop from 2008 with 4GB of ram that runs a modern KDE desktop and related applications just fine that I use for troubleshooting stuff. However, the moment I open a web browser it basically falls to pieces. I hate everything about this. :-/

That's easy to fix: Step 1: sudo tee /etc/tmpfiles.d/mglru.conf

I'm on an older LTS kernel so no support for lru_gen but I will definitely check out zramswap - thanks.

Re: 200 MB RAM FreeBSD desktop

#155

Post by zozbot234 »

lostmsu wrote: post #152
zozbot234 wrote: post #150

Earlier quoted context omitted.

You need window surface buffers in order to do seamless compositing, scaling etc. It's quite technically possible to achieve pixel-perfect 2D rendering with GPU-side compute, but in many ways it's still an open problem.

Scaling is for legacy apps, right? Modern apps should get the area to render and the desired pixel density. Not sure what you mean specifically by "need" in "need ... to do compositing". Compositing is just a way (e.g. rerender only on changes, cache results) of running a desktop environment. Strictly speaking you don't need compositing, you can just use immediate mode across the DE and apps. The tradeoff of course i…

> Modern apps should get the area to render and the desired pixel density.

What if you want to smoothly slide an app window over to a second monitor with a different pixel density? That's admittedly a very rare thing, but some people seem to be obsessed with it and insist that it must work. You either have to compose some window surface, or just use clean vector rendering throughout.

Re: 200 MB RAM FreeBSD desktop

#156

Post by lostmsu »

zozbot234 wrote: post #155
lostmsu wrote: post #152

Earlier quoted context omitted.

Scaling is for legacy apps, right? Modern apps should get the area to render and the desired pixel density. Not sure what you mean specifically by "need" in "need ... to do compositing". Compositing is just a way (e.g. rerender only on changes, cache results) of running a desktop environment. Strictly speaking you don't need compositing, you can just use immediate mode across the DE and apps. The tradeoff of course i…

> Modern apps should get the area to render and the desired pixel density. What if you want to smoothly slide an app window over to a second monitor with a different pixel density? That's admittedly a very rare thing, but some people seem to be obsessed with it and insist that it must work. You either have to compose some window surface, or just use clean vector rendering throughout.

Windows doesn't care and neither do I. But still, this can be done in immediate mode if the DE can tell the app it wants it to render the window in multiple rectangles with different pixel densities.

I have a hope for the whole idea, because imo it could significantly improve text rendering in VR by passing or allowing realtime access to the projection matrix along with the areas to render to. Regular VR compositing distorts text and vector graphics due to reprojection.

Plus, as noted above in VRAM speed vs GPU compute speeds, it might actually be faster and more power efficient overall if done right. See e.g. the famous Windows Terminal optimization issue with glyph atlas caching and object reuse.

Re: 200 MB RAM FreeBSD desktop

#157

Post by skotobaza »

undeveloper wrote: post #21
ryan-c wrote: post #18

opens blog post sees lunduke closes blog post

seriously, what's with people's love of this guy? besides politics, I have not seen anything that suggests engineering prowess from this guy, only "rust bad".

I think he did a good job with a report on Mozilla's spendings. Also in general he shows a lot of cases of hypocrisy in the modern software industry.

Re: 200 MB RAM FreeBSD desktop

#158

Post by ValdikSS »

alyandon wrote: post #154
ValdikSS wrote: post #125

Earlier quoted context omitted.

That's easy to fix: Step 1: sudo tee /etc/tmpfiles.d/mglru.conf

I'm on an older LTS kernel so no support for lru_gen but I will definitely check out zramswap - thanks.

Then also do this:

    echo vm.page-cluster=0 >> /etc/sysctl.d/85-swappiness.conf

Re: 200 MB RAM FreeBSD desktop

#159

Post by overfeed »

dTal wrote: post #106

I remember, in 2007, running FreeBSD on a desktop with 512MB RAM and only using 64MB of it running full GNOME 2 and a running instance of Firefox with a couple tabs. A totally standard desktop experience. Even better, my laptop at the time had only 128MB of RAM and ran Windows XP - a supported, albeit minimal, configuration. XP was bloatier than FreeBSD of course, and ran correspondingly less well, but replacing expl…

> It is difficult to say.

It isn't: you can still download the 2007-vintage FreeBSD desktop and run it in a VM today if you'd like. The CD image-files are quick downloads with modern broadband speeds. Prepare to be disappointed though.

Re: 200 MB RAM FreeBSD desktop

#160

Post by iberator »

stavros wrote: post #36
badc0ffee wrote: post #8

I remember booting up Debian into an X11 session on a laptop with only 8 MB of RAM. (This would have been circa 2000, and I think I had to try a few different distros before finding one that worked. Also I don't think I did anything with it beyond Xterm and Xeyes.)

My first PC had 16 MB of RAM, which later obviously became too slow to be usable. I remember I had to wait around a minute for Fallout to load a level, which you had to do fairly frequently.

4 minutes to load Enclave level save game with pentium 200mhz with 32mb ram
Post reply on HN