Hacker News new | past | comments | ask | show | jobs | submit login
A Memory Comparison of Light Linux Desktops (l3net.wordpress.com)
101 points by tanglesome on July 8, 2013 | hide | past | favorite | 80 comments



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.


My ram is fast. My disk is slow. I want things to be in ram to be ready for when I need to use them.

The amount of ram a software uses seems like an odd metric to use, especially when the ram hungry beasts mentioned in the article use less than 250 MB.


I don't think the problem with the more hefty window managers is that they use a lot of RAM, but that they have to use a lot of RAM.

IMO, the fact that they require more memory can be considered a reasonable indicator that they are more complex / do more stuff. They need to read stuff from disk / generate data in order to fill that memory in the first place, which takes time. I'm not an expert, but I would guess that using more memory also increases the chance that some of it will be swapped to disk by the OS, slowing things down further (although only intermittently).


Yes, but at the same time, they are doing more. You get what you pay for.


You've said what I meant to (but didn't) say.

Comparing IceWM and JWM seems fair, because they both do the same thing. Comparing JWM with Gnome3 only on memory used for a vanilla instal is weird.


I guess I don't see the contradiction: given finite memory, you'd want as much for your applications as possible, right? We don't buy computers to run window managers, after all. And even if 100MB seems 'small' nowadays, it's as valid as ever to point out that maybe that's 100x more memory usage than some other piece of software.

Besides, it's interesting to see that E17 is hardly 'lightweight', and XFCE is actually 'heavier' than MATE. WindowMaker (woo hoo!) is surprisingly 'lighter' than Awesome. I'm glad it will cut down on the X-is-slow-use-Y-instead-it's-lighter crap. Hearsay and fanboyism are endemic to linux wms, it seems.


I think they are just trying to figure out which WMs are most memory efficient.

You and I know as geeks that irrespective of real-world use, metrics and numbers are a good thing to throw around and make us seem smarter and more efficient than we actually are. :D

I was intrigued by the results - but will still keep using Unity myself (I love Mate/Cinnamon too) though its second last!


It is a good metric to use precisely for the reason you state. You want your applications to be in RAM. You want your files to be cached in RAM. You have finite RAM. The less RAM your system is using, the more is available for applications and files.


Just came here to say: i3 is really nice. It's too bad he didn't mention it, it's one of the more lightweight WMs in his bar chart.

If you haven't tried it, give it a shot. Was always intrigued by tiling WMs but resisted for far too long because of a vague resistance to learning yet another set of keyboard shortcuts. Seriously though, it's not bad at all.

http://i3wm.org/


I've been using i3 for a few months and I love that I can boot in 5 seconds from power to i3.

He mentions i3 in a previous article, this is why it's on the bar chart.


Link for the lazy: https://l3net.wordpress.com/2013/03/17/a-memory-comparison-o...

Also covers XFCE, awesome, *box, etc.


I'm curious why you choose i3 over Awesome or Xmonad. I recently started playing with tiling window managers myself after I saw a i3 presentation on Youtube. When started looking into it I found much more documention on Awesome wm. That's why installed that one on my machine.


I've been using i3 for about two years. I sampled a few other tiling WMs, including awesome, before settling on i3. Realistically there isn't much difference between them in terms of the features that I personally use, but these are the main things that sealed it for me:

* Tree-based/hierarchical tiling.

* Simple as hell multi-monitor.

* Beautiful config file [1].

* JSON API [2]

* Modal, vim-like key bindings.

[1] http://code.stapelberg.de/git/i3/tree/i3.config [2] http://i3wm.org/docs/ipc.html


I haven't used i3, but I did use awesome for about a year before settling on Xfce. The thing all the tiling window managers don't have is a compositor. I don't care about shadows or animations, but it makes everything seem smoother and faster. The compositor in Xfce uses xrender instead of opengl, so it works pretty well even on low-end machines.


Wish there was a cool reason to tell you, but it was just because somebody happened to be extolling the virtues of i3 in a similar HN discussion a few months back, so I gave it a whirl. I'm sure Awesome and Xmonad are great too, but all my needs are met so haven't really had a reason to shop around.

Looking back on all the hours I used to spend tweaking and fiddling with configs for things that I no longer use has made me sort of a setup minimalist -- anything that's not broken for me usually stays pretty close to stock these days.


Awesome is nice, but is much more heavyweight. It depends on Lua, and the dialect of its configuration file changes.

i3wm has no such dependencies, covers 80% of awesome's use cases, and is stable.


What kind of things does Awesome excel at what i3 can't or doesn't do well? (Awesome user here)


I have dabbled with many WMs, including i3. I have settled on awesome. These are the shortcomings of i3 for my usage.

1. Multimonitor. i3 has 9 tags that are shared between all attached monitors. So, if you have 3 monitors, the distribution of tags may turn out to be [1,4,5,6], [2,8], [3,7,9]. You can move tags from monitor to monitor, but AFAIK, you can't exceed 9. I have a habit of keeping email, browser, music player, and chat program on one tab each. So, this limitation of 9 tags just kills it for me.

2. awesome has better placement of floating windows.

3. Vertical task/status bar. This is a minor issue, but I wish i3 comes with one.

If i3 fixes these things, I'd switch to it in a heartbeat. i3 has a saner config, and a much more elegant tiling layout.


You can certainly have more than 9 tags on i3. In fact you can have tags with arbitrary names. They are a bit more difficult to manage with the default config, because only the default 9 have keybindings. But you can create your own tags and bind keys to assign windows to them or switch to them with a custom config.

You can also use a tabbed window layout (Super + E) to keep multiple programs full-screen on one tag. Then you can switch between them with the tabs at the top or Super + J, Super + ;.


What do you think is lacking in i3's documentation?

http://i3wm.org/docs/


I had to use my daughter's modest ASUS AMD C-60 All-in-One (2 Gb RAM) until I could find a replacement for my laptop. Using Ubuntu's Unity with a LAMP and/or Rails stack sometimes brought it to it's knees. Switched to i3 and it was like having a new PC. No kidding.


I'm currently using i3 as well and enjoy it.

The only issue is with certain java-based applications such as PyCharm or Arudino IDE, in which sometimes the windows aren't drawn correctly due to the JVM not playing nicely with "non-reparenting" window managers (such as i3).


There's actually a workaround for this.

Most Java distributions have the ability to work with non-reparenting WM's, but they detect it based on the window manager name.

So the workaround ends up being impersonating another non-reparenting WM, for instance Sun's Looking Glass.

http://awesome.naquadah.org/wiki/Problems_with_Java


Shame he didn't include xmonad, on my pc it takes about 7/8 MB, but I guess you also have to consider another 4/5 MB for xmobar.


I don't run xmobar or trayer...

It's nice that we don't need to write these things in C to be small and fast.


Me neither and I can't work without XMonad.Prompt, especially the Shell instance, for spawning executables. I don't remember Tuumo's ion in detail but the only other launcher that behaves similarly in a sane way is cwm's built-in menu. dmenu_run doesn't work the right way and is limited in what it launches or auto completes. Like ion there are also instances for ssh and man pages. When using the shell prompt the memory usage goes up by 1 or 2 megabytes but that's constant. Any time I try spectrwm or dwm I always come back to xmonad.


Trayer too (if you use it). I'll have to take a look when I get home to see how it all adds up.


You can try taffybar [1] but it's a bit more involved (I don't think it's packaged anywhere). Has both widgets, task bar and tray.

1: http://hackage.haskell.org/package/taffybar


Why consider a 1MB window manager, when you are running Firefox (or Chrome)? The browser is easily the most memory-consuming app on most PCs.


Up until December 2009, my main computer was a desktop we'd bought in 2000. At some point, we had upgraded it from 128MB of RAM to 384MB.

That last year or so, things got rough. I was really pushing the limit of what it could run without feeling unreasonably sluggish (with pretty normal workloads of browsing, IM, and either word processing or Ruby coding). First, I switched from Firefox to Opera. Then, I switched from Gnome to Xfce to IceWM. This made a world of difference, and I really didn't miss Gnome. It got me another 6 months+ out of that computer without being terribly frustrated all the time.

In most cases, on a modern computer where you have multiple gigabytes of RAM, I agree with you. But it's still nice to have those tiny window managers around.


Depending on how you value your time, a $300 computer will run circles around a 10-year-old computer, and will be far cheaper than the time spent trying to shoehorn modern applications onto old hardware.


There's something quite satisfying about breathing new life into an old piece of hardware, or extending its life further as in this case.

So although I agree with your point it's nice to not have everything boil down to dollars and cents all the time :)


This is why I prefaced with 'how you value your time'. I completely agree with you. If you're just after something that works, then just buy a new computer. If you like the project of injecting longevity, then the tradeoff is that you're getting entertainment out of your hours.

I'm very much a 'not dollars and cents' guy, but I see a lot of people struggle to maintain old computers when they're not really into enjoying that maintenance activity; those for whom an hour of troubleshooting -foo- is pure frustration with no fun mixed in.


So what? Are you saying that one should run a memory hungry window manager just because you are going to run a memory hungry app inside of it?


To me, the main take-away from the article is that there's more to life than KDE/GNOME, especially given the number of comments showing that the alternatives do have real users. If we apply that logic to browsers, we find that there's more to life than Firefox/Chromium. For example, I'm writing this from w3m running in XMonad at the moment :)


To a Very crude first approximation, you could expect KDE to be 201 times slower than ratpoison, or rephrased you could have 201 times less user latency using ratpoison than KDE. Or ratpoison gets out of the way of the user "two hundred times faster" than KDE so for the average user it would be about that much more productive, with a correction factor for whatever proportion of time users play with WMs/desktops vs doing actual work in an app.

Also there's a fair number of machines out there, used for non-web browsing purposes, yet might still have a use for a GUI.

Lets say you want a virtual cloud host, connected to via VNC to ... linode. The smallest linode is a gig, so you'll be using 1/5 of your total resources just for the window manager if you use KDE. Is that relevant, well only you can decide.

Finally the most interesting part of the graph was the exponential-ish nature of it. For some weird reason I was guessing WMs/Desktops grow vaguely linearily over time so a random sample from random aged WMs would be vaguely linear when graphed... that's not whats happening. Have not come up with an adequate mental model to explain the shape of the curve yet, assuming the data gathering wasn't manipulated to specifically generate it. Maybe its an attractor effect where one pole pulls to 0 or as close as you can get, and the other pole pulls to infinity, or as close as you can get (kde) and everything smoothly distributes in the middle ground.


"To a Very crude first approximation, you could expect KDE to be 201 times slower than ratpoison,"

Uselessly crude. What matters is how much code is on the critical path and how long it takes to run, not how much is loaded into RAM. A JPEG library loaded into memory that is not used when switching between windows doesn't impact window switching time. Contrariwise, KDE may have many thousands of times the latency if it tries to do many DBUS calls or something for an action that a simpler window manage would simply perform in-process. And it may not matter because "many thousands" of times the latency may still end up below the human perceptual threshold anyhow; 5ns vs 5ms is a whole lotta difference, except it sort of isn't when it comes to humans, both are instant.


I use ratpoison, the 1MB window manager. I'd still use it if it took up a 1GB or whatever because it still is my favorite wm. The low memory footprint is a nice perk, specially when it's running alongside memory hogs like firefox.


So there's more room for Firefox or Chrome.


Which is definitely something worth measuring, as a browser pull in lots of shared libraries, which often cause some of the gap between bare window managers and desktops to decrease, especially if the WM isn't using a UI toolkit in the first place.

Also, given the memory need of modern webapps, I wonder if even the delta between the two extremes amoutns to more than one or two opened tabs. Of course, if one or two tabs is all that your machine can handle, this is significant.


because it _is_ better, without all unneeded bells and whistles. besides, a browser is not the only app you run, right? If not go and buy yourself a tablet, and don't use PC, as you don't need them.


Because you can.

Why does every choice need a 'business case?'


I had a nightmarish scenario a few months back where I was just trying to wipe an old hard disk on an old laptop that still barely worked, so that I could ship it off to an electronics recycling place. It was I think 512MB of RAM but might have been less; but a few popular Linux LiveCDs wouldn't boot without running out of RAM, and my `prng` script uses Python3 among other things. After trying desperately to set up swap on a thumbdrive before the computer ran out of memory, I eventually just caved in and went to a comp shop to find an external hard drive case for old laptop drives. I was lucky, found one for relatively cheap, and wiped it from my own computer. And doing that sort of command from your own computer is quite terrifying even if you think you've taken the proper precautions, you're still double-checking everything to make sure that /dev/sdb is really where the random bits and then zeroes should go.

So these articles are appearing a little after I'd have liked to see them but they're a welcome overview in any case. :D


This has been one of the most helpful PC troubleshooting tool purchases I've ever made:

2.5"/3.5"/5.25" SATA/IDE to USB 2.0 Adapter ($17.99) http://www.newegg.com/Product/Product.aspx?Item=N82E16812232...

Also, I usually pull out the hard drive I'm worried about accidentally wiping and boot from a live CD.


Or you could have just booted to a console with no WM at all and wiped it?


He could also have used /dev/urandom to generate his random bits instead of running a python script.


Or /dev/zero, much faster.


I wanted to get some data off an old Windows 98 laptop of 1999 vintage. 4Gb hardrive, 1 usb port, 64 Mb of RAM. It worked fine in Windows 98, but back then anything USB required extra drivers and ... well, let's just say I didn't think re-learning Windows 98 at this stage in my life was a worthwhile investment.

In the end, I used Damn Small Linux live-booted off a CD and copied the whole drive to a USB stick. Took hours due to only having USB 1 back then, but it worked. Your external drive case is a better solution, but the "old distro" approach is great for cheapskates :-)


Why didn't you just take the hard drive out and take a hammer or power drill to it?


This might have been more fun but there exists the possibility that someone might ransack the laptop for components, and I actually like the idea that they might be successful.


You only need to overwrite a single time with 0s to make sure noone can recover the drive. (But using the drive's secure erase ata command is better.)

Or you could have used DBAN, which has modest min spec requirements.


I thought that too but late last year one of these Bradley Manning articles seemed to suggest that data might be able to persist after a simple zero-fill, so I thought I'd use my prng script before zero-filling, because it's as fast as zero-filling and it seems unlikely you could decipher more than two layers.

I looked up the article; the statement is actually more ambiguous than I recall:

http://www.wired.com/threatlevel/2011/12/manning-assange-lap...

"Johnson testified that he found two attempts to delete data on Manning’s laptop. Sometime in January 2010, the computer’s OS was re-installed, deleting information prior to that time. Then, on or around Jan. 31, someone attempted to erase the drive by doing what’s called a “zerofill” — a process of overwriting data with zeroes. Whoever initiated the process chose an option for overwriting the data 35 times — a high-security option that results in thorough deletion — but that operation was canceled. Later, the operation was initiated again, but the person chose the option to overwrite the information only once — a much less secure and less thorough option. All the data that Johnson was able to retrieve from un-allocated space came after that overwrite, he said."

It's not clear what "after" means exactly, but it surprised me that he learned about the first attempt after the second attempt was complete. What may have happened -- making this much less impressive -- is that maybe /dev/sda1 was filled with /dev/zero rather than /dev/sda, so that the first part of the drive was totally untouched. So it might be much less impressive than it sounds, but it sounded impressive to me at the time.


For this reason I have a drawer full of hard drives, its just so much easier.


Why would you have a drawer full of harddrives when, with the aid of a screwdriver, you can have a fridge door covered in magnets!


This is because you don't know what's out there.

Damn Small Linux runs in 16MB of RAM and provides a GUI by default:

http://www.damnsmalllinux.org/

tomsrtbt runs in less, but provides no GUI and very little documentation:

http://www.toms.net/rb/

http://www.linuxtoday.com/news/1998122400805PR

My point is that not everything needs to be small. We have freedom of choice here, not one-size-fits-all, and we can create specialized distros for specialized tasks.


Right, it's more that those were the LiveCDs which I had on hand to try and I didn't want to research alternatives. What I really should have done at the time is to ask around on Freenode or some other IRC network; someone could probably have answered the question quickly.


I like how the author editorialized about the RAM use of Unity ("Too bad it runs in 192MB of memory! It would be a good idea to trim it down, let’s say by 50%. As a note, DOS conquered the world by running in 64KB of memory.") yet said nothing about KDE's, while KDE in "bare minimum required" mode required more RAM than Unity did.


I've really enjoyed using stumpwm: not only is it a tiling WM like ratpoison (in fact, stump's a successor to ratpoison, written by the same guy) or xmonad, but it also means that I always have a full Common Lisp running, which I can connect to in emacs via SLIME.

It's not quite as good as a Lisp Machine, but it's better than nothing.


I find this comparison to be flawed in that the base system used is not very frugal.

Tiny Core gives you a GUI desktop in an under 12 MB iso.

http://distro.ibiblio.org/tinycorelinux/

That said, I'm sticking with FreeBSD & dwm.


I use XFCE because I run debian in a VM inside MacOS and I don't see much reason to run two RAM guzzling window managers (I have lots of RAM so I can run scientific code that often needs 4-5GB at once, mostly for python code I intend to optimise when I have time). At 70MB by this measure, it seems like I made roughly the right choice for a window manager that leaves me lots of other space free for 'real' data (but still loads enough of GTK to run Eclipse as my dev env.)


I'ts weird to say this, but I actually quite like the interface of Windows Vista and up. Xfce and the likes always were enough for me. But there is one tiny little feature I miss. Sortable windows on the taskbar.

I guess one day I have to write my own window manager and taskbar adding to the huge amount of stuff that's already out there.


Sortable windows are there in Xfce taskbar, but maybe you meant they are not in recent Windows version (I do not use them often enough to remember).


[edit] Nevermind, found it. Seems to have been removed and brought back a few versions ago. Neither as useful nor as visually impressive as the Windows version though.

No I meant Xfce. I can't find that function. Are you refering to sorting by rules? I mean ordering windows by drag and drop. As far as I know no window manager or desktop environment allows that except the Windows desktop. It even does it in an very elegant way.

If I have VirtualBox open and a machine running I can drag both windows in the taskbar together and say, position them behind my browser.


Since I do not use the sortable taskbar I never noticed when they removed and then re-added it so I assumed it had always been there.


Getting rid of mysqld and the file indexer should make KDE run in just under 100 megs. Decent for what it provides.


Wow, I thought this was a bad joke about KDE being bloated. It is not, KDE actually requires a local mysqld instance for PIM data:

http://www.bytebot.net/blog/archives/2009/02/19/kde-42-bring...


Yeah, initially it gave me a real heartburn but given the state of Gnome 3 I decided to live with it! Some enterprising programmer should really rewrite from scratch a light weight but functional Exchange/IMAP client and calendar app. Heck I wouldn't mind taking the Android code and using Java UI bindings for KDE if that's what it takes :)


For the uninitiated, PIM apparently stands for personal information management (calendar, address book, etc).


I'm very happy with xmonad. I'm running a very minimalistic desktop consisting of fast applications that do one thing, do it well, and can be controlled from the keyboard (zsh, urxvt, emacs, remind, mutt, zathura...).

As a very welcome side-effect, the whole thing is very light. It runs in a few tens of MB.


As an aside, I never knew about Trinity[1] before this article...I am spinning up a VM to try it out on right now, as I always liked KDEs style, but disliked the bloat.

1: http://trinitydesktop.org/about.php


You get what you pay.

A international CMS, or a static .html ?

This is the same.

If you just need to throw a paragraph (or to "just manage "other programs" and forget about the "environment" and you don't feel it's slow, then... any of the two options is ok.


Are you running out of RAM when using a desktop? If not, why even worry about the memory usage?

More useful would be, "How long does Firefox/Chrome/etc open in this WM". If there is a difference then that would be more meaningful.


I've dipped into swap due to virtual machines. It was extremely painful.

But the article mentions this in the conclusion:

> If you have some ancient hardware that you need to breathe new life into, or if you need to fit a distro on a modestly sized memory stick, the first thing you should look at is the window manager/desktop environment.

For me, it's a lot easier to drop Unity for XMonad than it would be to switch away from something like Chrome. If I actually want to do something with one of my old laptops, this might be relevant.


Man, KDE is heavy. Plasma-desktop takes up 194MB here (which matches nicely with his +7MB openbox session), but Kwin, as most KDE users will arguably have, adds 99MB.

So a total of 293MB for KDE. Almost double as much as Gnome 3.


Is memory consumption a real problem for desktops in 2013?


The OS will use free memory for disk caches which will help speed up any modern desktop. That's the 'cached' column output by `free`. My computer currently reports 18 GB used out of 20 GB, but 15 GB of that is disk caching.

The more memory your desktop environment grabs, the less memory is available for disk caching. It might not be a problem, but it certainly pays off to invest in extra memory and in decreasing memory consumption of applications.


Yes. My first computers TRS-80 through to Amiga had massive advancements in capability, and while the memory increased with each step it was the gain in power that drove upgrades. Since then the pressure to upgrade has been primarily memory. CPU has not really been an issue because the memory pressure forces an upgrade by virtue of new memory module architecture necessitating a new motherboard.

The machines I am currently using perform poorly because they do not have enough memory. I'm in the saving-for-a-new-machine phase, suffering poor performance on computers with more than adequate CPU power.

It must be said though, the Window Manager probably plays a very small part of that load. While browsers take a major single chunk. Much of the drain comes from the accumulation of everything. So many apps have a philosopy that "an extra 20(0) meg doesn't matter when you have gigabytes" that eventually they combine to actually eat up your gigabytes.


If you play around 1) older machines, or 2) desktops in VMs, it's handy to know what uses less memory. I used to use XFCE in these circumstances but have switched to LXDE based on comparisons like these. Good balance between memory usage and utility/familiarity.


tbh the need for this is steadily decreasing. Sure I've got some old laptops that might need this spec wise but frankly by the time I've installed & set it up I'm already contemplating suicide. Systems with that little RAM also tend to be seriously slow...




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

Search: