Hacker News new | past | comments | ask | show | jobs | submit login

This doesn't make a whole lot of sense. No, no, I'm not about to play down memory consumption as an attractive means to a fast UX. I see a point there: Accessing that memory will take its time, being it RAM or not. However, memory consumption is a bad metric. One back-buffer of the background image, if any present, will make a difference of some megabytes.

The most important part, however, is to shed light on "memory consumption" and how to measure it. The latter is a hard, hard task and there are odds in the game. The values given by "free", specifically, are only a (bad) indicator for the full system. E.g. have a look at those "buffers" and "cache" values. A lot of factors play a role: filesystem (c.f. btrfs vs. ext2), allocator (glibc?), sharing of dynamic libraries. I would specifically emphasize the last one: When you're about to run mostly GTK based apps, you will probably profit when your desktop has already pulled all GTK related dynamic libraries into memory (e.g. GNOME, XFCE). Whereas some minimal window manager might have a small memory footprint because it merely uses the Xlib/Xcb - an advantage over the moment you start Firefox or GVim. Or you might want to use Qt based apps - and that may profit from a desktop that pulled Qt in before (like KDE and others).

Having a compositing window manager also makes a difference memory-wise.

This said, pure code footprint _could_ be measured. It would be a hassle though. And in the end, the real noteworthy differences are those you can measure in actual time passing. Be sure to not only measure start-up, though.




Agreed.

Xorg + a few fonts is more "heavy" (in memory numbers) than the 90% of those dm/wm,

There are tools like x11perf, glxgears, and more, and at the end of the day, you cannot compare "fluxbox Vs a desktop environment", because you should be comparing fluxbox + cups + a desktop search indexer + a graphical filebrowser + a calendar service + this + that + ...

It's nice to see "the data", as "numbers", but you make a proper point about how it should be interpreted.

When I had more spare time (this is more than 14 years ago), I did test a lot of desktop environments. I did start with kde 1.X, and have use many version of many desktop environments and WMs... my tip is: pick the one that makes you "forget about it" and focus on your tasks.

Now living out of home and al the hardware I carry, and have access does not have any problems. When I loved at my home, I had recycled computers, and repaired by me ones, and if it was not ok for a graphical ENVIRONMENT (I don't care if I don't swap after boot, I care if I swap WHILE USING) I just did use such machine as a "headless server" and everybody is happy.

Other approach to low resources machines as the blog seems to talk about, is to enable remote login (xdm, gdm, kdm, whatever) on a powerful machine, and use the old one to just launch the X (raw) and the remote login/desktop client in full screen.

A few years ago, I did see this numbers on my own for the environments I was interested, and people used to tell me "xfce is light!!!", obviously, they did come from lighter environments, maybe because they were used to heavier desktops. I was used to fluxbox.

I was used to _forget_ about the WM and the backgrounds, and focus on useful things (unless you are preparing a your screen for a Hollywood film or something like that).

I just ask a responsive workflow. Most system do not provide that "by default" and you have to "setup", "cleanup" or "shortcut"... you can do it in many ways at many layers.

I like fluxbox by the following reasons: we did meet years ago, recycling computers with low resources, I did learn the configuration (behavior and keyboard) in half an hour and a few days of tweaking, performance/resources never was a problem, I did forgot about "it" and "it" did let me "do stuff". Until today this never failed/changed. That are my "numbers", I'm a happy customer.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: