I'm not talking about crazy stunts like running in 48M; here I'm talking about running a fully fledged system.
I've been doing a bit of testing of the upcoming release, which includes running the install under a range of configurations. The test here is to boot the ISO image in VirtualBox with a range of memory sizes and then install the kitchen sink.
- The live image won't boot at all on a 256M system
- The live image will boot on a 512M system, but installing to zfs will fail
- However, installing to ufs works on a 512M system
- With 768M, installation to zfs is rather slow
- With 1G or more, you're fine
That change explains the 256M failure - the ramdisk is about 300M, so it simply won't fit. It's likely to have an impact on the 512M case too - in the old scenario you only paged in the bits of the /usr filesystem as and if you needed them, now it's locked into memory.
On a limited memory system there's a way to make things a bit easier. Simply install the base (no additional overlays) from the installer, then add the rest of the overlays and packages later. The point here is that running from disk doesn't lock up anywhere near as much memory as the full OS being resident in RAM does. And some of the packages in the kitchen sink are rather large, which causes problems.
Once you've got Tribblix installed, how well does it cope? Surprisingly well, to be honest. The Xfce desktop runs quite well in either 512M or 768M of memory. I can run firefox on the 768M system without too many problems (given the way it consumes memory, probably not for a long intensive browsing session), while firefox on a 512M system does run, but it's clearly starting to grind. Java applications work, some smaller ones at least. You need to be realistic in your expectations, but the point is that smaller systems do work.
The most limited systems would tend to be older, possibly 32-bit hardware. I could build a 32-bit only image which would be quite a bit smaller - maybe only two-thirds the size. (And if you really wanted to you could get it even smaller - but then you're in the realms of building custom images using mvi or the like.)
However, the aim of keeping Tribblix viable on smallish systems isn't just to allow the use of old hardware, beneficial though that is. If you're running a service on a cloud or hosting provider then being able to use a 1G server instead of a 2G server will halve your costs, and that's a very good thing to be able to do.
3 comments:
Why could Solaris 7 run in 128 MB of RAM but newer systems, like Open Indiana or Tribblix, can't. Solaris would use up all the RAM and then immediately swap. But the swapping was so efficient that I didn't notice. I had to study the memory situation to figure out what was happening. Why can't other system swap as well as Solaris? Windows also swaps well. Linux is terrible at swapping. Is Tribblix really that much bigger than Solaris 7 that it requires so much RAM? What is it that makes it so much bigger? As a user, I don't see whatever benefit I'm getting from it being so much bigger. I'm not trying to be a pain in the butt. I'm asking an honest question.
The real change is that in 4 major releases a lot of additional capability has been added - SMF, zones, ZFS, FMA, Crossbow, and a huge number of changes under the hood.
In addition, the installer is really quite different - it's a ramdisk, which means the installer has additional memory requirements. And as you need to run the installer before doing anything then that imposes the lower limit on memory configurations.
I've run Tribblix in 48M of memory. If you want Solaris 7 levels of functionality then it'll run in 128M just fine (it will need a custom installer). But the same issues apply to applications - modern applications require far more than 128M to run, so they will be a problem.
Thank you for the good explanation.
Post a Comment