Is it good for your use case or will it explode?
Mate 20.04 runs great on 2GB, therefore I think 22.04 will also be no problem 
Maybe this is a good illustration how lightweight/mediumweight MATE-desktop is :
I have a small netbook somewhere with an AMD C60 processor (comparable to an old intel atom but slower) and 1GB RAM but 250MB is strictly reserved for graphics by the system so I actually have effectively 750MB RAM to spare for the OS and all applications.
It came installed with Win-7 starter and it was unworkably slow, even with only notepad.exe open.
I installed the 32-bit version of Ubuntu-MATE 18.04 LTS and although it was not really a speedmonster (which is not a surprise with a C60 processor) it was workable and chugged away really nicely. It could also run FullHD H264 (AVC) video without a problem. It did use a little bit of swap but not much.
Another old Laptop of mine, (P4 not capable of 64-bit dated feb 2004) has 2GB RAM and that amount of RAM was much more than I ever needed (32-bit Ubuntu-MATE 18.04 LTS again).
Ofcourse it all depends on how much resources your applications demand but I have a hunch that 2GB is perfectly workable
5 Likes
You might consider trying the live iso and select try(not install) option to actually see on your system how apps you want will run. I have 16gb. but used try mode to see if a critical app I use would work in 22.04 and it did. Would be more conclusive as have seen some users with multiple cores and 32gb. ram (have to have latest and greates) that only use for email and web surfing. 
4 Likes
Sorry, I'm going a little off-topic here, but when I saw the mention of your netbook running Ubuntu MATE 18.04 32-bit, I couldn't resist spewing some advice (and a rant) about 32-bit versus 64-bit. The following content will be controversial I know, and everybody I've ever told this to has always blown it off and called me insane; but I don't care, because I need the truth to emerge. I don't care what people think should theoretically happen; I know what I've seen.
Ignore it, or use the information, at your own discretion.
Actually, and counterintuitively, I strongly suggest you try the x86-64 version of Ubuntu MATE on your AMD C-60. (At the very least, I'd recommend you try it first from live DVD / USB, as @mendy suggested.) It might actually work faster and with less memory usage than the 32-bit version. The difference in memory usage will probably be slight, but the speed difference could easily be considerable. Here's why I think so.
Intuitively, you'd think that the 32-bit version of an application or an entire operating system would be far smaller than the 64-bit version. After all, there's twice as many bits to fling around, right? Wrong. When Intel moved from 16-bit instructions to 32-bit in 1985, Intel decided to use the simple approach: Instructions that would previously have included explicit 16-bit parameters, now included 32-bit ones in the place of the 16-bit parameters. This nearly doubled code size in some cases -- it wasn't actually that bad, but it did appreciably increase code size. But when AMD designed x86-64 (yes, they designed it, not Intel), AMD had the wiseness to design x86-64 so that program instructions wouldn't always have to use 64-bit parameters. Actually, to my knowledge, there is only one instruction in all of x86-64 that even accepts a 64-bit "immediate" parameter. All other instructions use 32-bit values and "zero-extend" the 32-bit values to 64 bits.
Now, there are some cases where code does bloat up slightly due to the instruction set change. In particular, memory addressing does bloat up from 32 bits to at least 48 bits, but again only 32-bit integers are used unless a bigger integer is necessary. And another source of code size increases comes from the fact that many instructions now need an extra byte prepended to the instruction, called a prefix, to use some advanced features of x86-64. But this is easily offset:
-
For one, 32-bit operating systems are highly backward-compatible with very old CPUs, and have to assume you could be running the code on a 60MHz Intel Pentium from 1993. (Last time I checked, somebody actually filed a bug report on Debian regarding some fundamental library using a feature not present on Pentiums. The bug report wasn't thrown out, which indicates that at least some of Debian and probably some of Ubuntu works just fine on a Pentium!) Such a processor is not only very slow (even compared to your AMD C60), but that Pentium is missing a lot of features of the x86 instruction set that were added since 1993. For example, the Pentium didn't have the
CMOV(conditional move) instruction, which is a very convenient and usually extremely fast way to copy one value to another place in the CPU. Without theCMOVsupport, applications would have to "branch" to another place in the code every time, essentially, anifstatement or a loop is executed. As much as CPUs may now be optimized to handle branches fairly efficiently, it's almost always better to avoid branching when possible since every branch runs the risk of being mispredicted by the CPU, and then the CPU wastes time dropping everything it was doing (yes, seriously!) and dealing with the branch gone awry.The same can be said for so-called SIMD instructions (SSE, SSE[2,3,4.1,4.2,4.A,5], AVX, etc.). SIMD instructions operate on not single integer or floating-point values, but sets of 2, 4, 8 or sometimes even more of them at a time. These are extremely powerful instructions when used correctly.
But the 32-bit OS, which is designed to work with the Pentium (OK, maybe the Pentium Pro these days, but that's still incredibly old), cannot necessarily rely on the CPU having any of these very nice features. So the code has to either forego using these powerful features, in which case your AMD C60 from 2011 is being treated like a Pentium from 1993, or the code has to include tests for the features present in the CPU. If the latter is done (and that's what is usually done on Debian/Ubuntu), then two versions of the code need to be included: one for old CPUs, and one for CPUs that include the feature. If there are multiple features that are useful for getting the job done, that's even more copies of the code that need to be included. And every copy of the code increases RAM usage.
However, 64-bit applications don't need to worry too much about missing x86 features. After all, among other things AMD decided to mandate SSE2 at minimum. So all x86-64 CPUs are guaranteed to include a very powerful set of x86 instructions, and because of that, 64-bit applications don't need to test for as many (if any) extra features of the CPU. So, because of the last point above even by itself, 64-bit applications can be smaller than 32-bit applications.
-
And then performance-wise, 64-bit operating systems and applications have a real edge. I don't care if people say that 64-bit applications don't have a performance benefit; clearly they're running the wrong applications. Among other benefits, 64-bit applications have access to at least double the number of CPU "registers" that 32-bit applications can use. The more registers that are available and put to use, the fewer things that need to move back and forth to and from the CPU (in other words, the less stuff that needs to be put in RAM). Believe it or not, RAM is actually insanely slow. In a bad case (actually a pretty common scenario), reading or writing RAM might take over 300 times as long as it takes to manipulate a register! While modern CPUs have cache memory and other performance features to ease the difference between CPU speed and RAM speed, an old CPU (with a comparatively small cache) combined with new software (bulkier than ever -- even MATE is bigger than GNOME 2 ever was, and I'm going to get in trouble for saying that
), is a recipe for silicon molasses. How do you like your molasses, thick or super thick? -
Also, AMD developed x86-64, so their hardware is probably better tuned to perform better in 64-bit mode than, say, Intel's (at least historically).
-
One weird thing that I can't explain at this time: I've noticed that 64-bit Linux kernels actually report more usable memory than 32-bit kernels do. Here's a stock Debian 64-bit kernel showing some memory statistics:
$ uname -a Linux debian 4.19.0-10-amd64 #1 SMP Debian 4.19.132-1 x86_64 Intel(R) Core(TM) i7-6xxxU CPU @ 2.50GHz GenuineIntel GNU/Linux $ head -n1 /proc/meminfo MemTotal: 12187456 kB [...]And a stock Debian 32-bit kernel:
$ uname -a Linux debian 4.19.0-10-686-pae #1 SMP Debian 4.19.132-1 i686 GNU/Linux $ head -n1 /proc/meminfo MemTotal: 12050072 kBEven though a missing nintieth of the memory might not make a difference on a system like this with 12 GB of RAM, it could make a difference on a system with 2 GB or less of RAM. I'm still not sure what causes this, but this is just one more argument to go 64-bit.
-
Finally, some applications actually don't even work correctly in 32-bit mode anyway. I run 32-bit Debian on my machines that simply don't support 64-bit (I run 64-bit everywhere else, believe me). When I use LibreOffice on 32-bit Debian, for still-unknown reasons, sometimes LibreOffice (the GTK style plugin to be exact) uses 100% of the CPU time, and makes the computer hot and (in the case of laptops) drains the battery really fast. There's a Debian bug report for this that's been open since 2018. Still nobody knows what the heck is going on. But one thing's for sure: The 64-bit version has been repeatedly tested for this bug, and it doesn't appear there.
I was surprised myself to find all this stuff out. Oh, and still nobody believes me -- they still think that 64 > 32 and thus 64-bit applications must not be a good idea on old hardware. But after years of ignorance about some of one of my client's machines being 64-bit (don't ask how we managed to miss that), I decided to try some 64-bit Linux operating systems out on those systems. And every one of the systems operated faster with a 64-bit OS than with a 32-bit OS. The biggest difference was on a very-late-model Pentium 4 (64-bit capable of course). For example, that machine booted 2.1 times as fast in 64-bit mode than it did in 32-bit mode, and 1080p video playback went from effectively unplayable (6 frames per second) to plenty acceptable (25 frames per second). I was baffled.
So, you might want to give 64-bit a chance. Maybe it'll perform miserably. But you might just lend a new life to your netbook.
5 Likes
The weakest box I use now in QA is
lenovo thinkpad sl510 (c2d-t6570, 2gb ram, i915)
where QA for me includes many flavors of Ubuntu (inc. Ubuntu-MATE). I find the box perfectly usable, but I'm very aware of what I put in RAM when I'm using a box with 4GB or less of RAM, using those boxes differently to my main box(es) which have 8GB.
As I still use boxes with only 1GB of RAM, I've learnt to be careful with RAM (less careful with disk space; my boxes usually contain more than a single flavor/desktop installed, but when I login I consider what I'll do in the session to keep my RAM usage efficient as thats impacts performance, ie. matching the apps I'll use with the desktop I select to be used)
I think performance really depends on how the box is used. What applications will be used, and what will co-exist in the limited RAM space you have available.
2 Likes
"Is it good for your use case or will it explode?" Neither
System Requirements: RAM 1 GB 4 GB
It will work, but be at the lower end of performance. Whether that works for you or not is up to you. Some people will be happy with that, other will be driven batty.
3 Likes
Hi @gordon ,
So, you might want to give 64-bit a chance. Maybe it'll perform miserably. But you might just lend a new life to your netbook.
It turned out you are absolutely right 
I tried it, and ....
.... I now run Ubuntu-MATE 22.04 (64bit) on a netbook with 768 MB
This is the hardware:
lsmem
Memory block size: 128M
Total online memory: 768M
Total offline memory: 0B
inxi -CGMm
Machine:
Type: Laptop System: ASUSTeK product: 1015BX v: x.x
Mobo: ASUSTeK model: 1015BXO v: x.xx
BIOS: American Megatrends v: 0610 date: 04/16/2012
Memory:
RAM: total: 699.3 MiB
CPU:
Info: dual core model: AMD C-60 APU with Radeon HD Graphics bits: 64
type: MCP cache: L2: 1024 KiB
Speed (MHz): avg: 802 min/max: 800/1000 cores: 1: 802 2: 802
Graphics:
Device-1: AMD Wrestler [Radeon HD 6290] driver: radeon v: kernel
Device-2: IMC Networks USB 2.0 UVC VGA WebCam type: USB driver: uvcvideo
Display: x11 server: X.Org v: 1.21.1.3 driver: X: loaded: ati,radeon
unloaded: fbdev,modesetting,vesa gpu: radeon resolution: 1024x600~60Hz
OpenGL: renderer: AMD PALM (DRM 2.50.0 / 5.15.0-56-generic LLVM 13.0.1)
v: 3.3 Mesa 22.0.5
And yes, I installed Ubuntu-MATE 22.04 LTS
This is what I changed after install:
replaced:
arctica greeter with slick-greeter
celluloid with mpv
rhythmbox with audaciousinstalled zswap
disabled unused ayatana indicators and plymouth splash
purged some resource hoggers (cpu and/or ram):
brisk menu
accessability options
mate-screensaver
all bluetooth related apps and libs (because this netbook has no bluetooth)
xapian
evolution
snapadded: classic-menu-bar
set: vm.swappiness = 90
This is the result after booting (free -h):
total used free shared buff/cache available
Mem: 699Mi 356Mi 45Mi 7,0Mi 296Mi 236Mi
Swap: 2,2Gi 2,0Mi 2,2Gi
Then I forced it to swap out a lot:
dd if=/dev/zero of=/dev/null bs=2G count=1
Result:
total used free shared buff/cache available
Mem: 699Mi 143Mi 509Mi 0,0Ki 46Mi 486Mi
Swap: 2,2Gi 272Mi 2,0Gi
Which means it can really make some space if needed
The machine is capable of running brave-browser, gimp, libre-office and FullHD H264based movies without a hitch and pretty fast (for its hardware/age) too.
It is only a bit sluggish with starting applications ( opening caja, for instance, takes about 2 seconds but after that it works painless and smooth and indeed a bit faster than on 32-bit )
So, you might want to give 64-bit a chance. Maybe it'll perform miserably. But you might just lend a new life to your netbook.
I, indeed, just lend a new life to my netbook.
Thanks, and thanks again for the incredibbly good written piece about 32-bit vs 64-bit .
This was awesome.
P.S.
for the stats:
I used to run 64-bit bodhi-linux on this machine which uses half as much ram as Ubuntu-MATE and never hits the swap.
I also tried Lubuntu on this machine but the difference in ram consumption between Lubuntu and Ubuntu-MATE is negligible.
4 Likes
Wow! I'm glad to hear that you improved the performance of your C-60!
And also, that is the first time (out of at least six attempts) somebody proved that I'm not crazy regarding 64-bit performance.
I hope your netbook continues to perform well!
3 Likes
Addendum:
There is this piece of software that I regularly use (Behringer X32 Edit for Linux) where a newer version did not run anymore on the C60 because of CMOV missing from the instructionset (or so I thought)
Today I tried that piece of software on the C60's 64-bit install.....and presto! It worked ! (as predicted)
Yay, I keep on learning new things, I love it
3 Likes
That doesn't sound like the CMOV instruction to me. The AMD C-60 supports CMOV (I checked) along with a host of other extensions up to SSSE3.
However, it does not support the Intel variants of SSE4, namely SSE4.1 and SSE4.2, only supporting the AMD variant (which AMD has since dropped from newer CPUs). I suppose it is possible that the software needed some feature of SSE4.1 or 4.2 to work. Maybe it was a "CRC" instruction? Because SSE4.2 included that instruction, and your AMD chip doesn't have it. Though I can't see musical synthesizer software seriously using an esoteric hashing function for anything, really.
Who knows? If it works, it works, I guess.
(BTW, CMOV first appeared in the Intel Pentium Pro processors of 1995. The CMOV instruction seems to have first appeared in an AMD processor with the introduction of the AMD Athlon in 1999. Therefore, any CPU that you're still using is pretty likely to have CMOV capabilities, I assure you.)
3 Likes
It is weirder than that:
Although it is proven that CMOV is present in the C-60 in 64-bit mode (Q.E.D.: app does run)
are you sure that CMOV is also available in 32-bit mode on a AMD C-60 ?
It seems that the application didn't think so, gave a CMOV error, and bailed out.
It certainly did not barf on an SSE CRC instruction, that much I'm sure of, because if the chip doesn't have the instruction in silicon/microcode, it wouldn't work at all, whether running in 32 or 64-bit mode.
B.T.W. It is not a synthesizer app. It is remote control software for one of the 32-channel digital audio mixers at my work (see pic):
And the app:
1 Like