as soon as i started doing two distros in one iso, i thought it would be cool to have an iso that would boot into a 32bit or 64bit version. someone else suggested the same thing to me the very next day.
i know there are multi-distro things out already. i dont know if any are 32/64bit puppy in a single iso. if one already exists, this isnt really "cutting edge" stuff.
nonetheless, it works. i have a script (this one can probably be done in just bash) that will put two puppy isos together, one 32bit and one 64bit.
this is here to let you know, you can probably do this with your favorite puppy version. i dont know how many of you are interested-- perhaps only one; and they want it to autodetect 32 or 64... i dont know of a bootloader that will do that.
this trick uses isolinux, but it could be done with other bootloaders. im probably only interested in doing this with isolinux and isolinux-based puppies, out of laziness.
32+64 single-iso puppies
Re: 32+64 single-iso puppies
stemsee claimed to do something simmilarlearnhow2code wrote:as soon as i started doing two distros in one iso, i thought it would be cool to have an iso that would boot into a 32bit or 64bit version. someone else suggested the same thing to me the very next day.
i know there are multi-distro things out already. i dont know if any are 32/64bit puppy in a single iso. if one already exists, this isnt really "cutting edge" stuff.
nonetheless, it works. i have a script (this one can probably be done in just bash) that will put two puppy isos together, one 32bit and one 64bit.
this is here to let you know, you can probably do this with your favorite puppy version. i dont know how many of you are interested-- perhaps only one; and they want it to autodetect 32 or 64... i dont know of a bootloader that will do that.
this trick uses isolinux, but it could be done with other bootloaders. im probably only interested in doing this with isolinux and isolinux-based puppies, out of laziness.
http://45.33.15.200/puppy/viewtopic.php ... 7dd7f22bc2
EmSee-Ultra-2016.iso i486 i686 x64 kernels boots on any machine! (needs confirmation!)
It might be worth looking at how your approaches differ and the pros and cons of each approach.
-
learnhow2code
Re: 32+64 single-iso puppies
true. my approach was to take a script that already combines two isos with a 32 bit bootloader (from puppy) into a single iso, and change the second iso it gets to a 64bit one.s243a wrote:It might be worth looking at how your approaches differ and the pros and cons of each approach.
the reason im combining two isos in this script wasnt to have more than one arch (although the point of this thread is that i was able to use it for that,) but to have other features from two distros.
puppy tahr and refracta (devuan,) with some features of refracta possible in puppy tahr, and some features of puppy tahr possible in devuan, mixed together before the new iso is output.
the 32+64 thing is another use of this.
-
gcmartin
At boot time, select your boot choice of 32bit/64bit version
@StemSee's series of distros over the past couple years offers any user the choice, at boot time, of 32bit system or 64bit system.
You merely download his ISO, burn/frugal it and boot. His splash screen give you the choice of which to boot.
Clever and nice. (Similar to what Knoppix has been doing for the past 9 years where it at boot time will boot.)
I had been hopeful that most PUP developers, by now, would have investigated and begun to present similar offerings instead of, separately, a 32bit distro version AND a 64bit distro version.
So, what so key about his offering is that instead of an ISO being one or the other, he gives the user one ISO that provides a choice to the user. Thus a user does not need to download a 32bit distro AND its 64bit companion. Instead, the users gets both built into 1 ISO.
The community is at a point where a developer who offers PAE 32bit and a 64bit PUP, today, would have followed his template to offer a single ISO for Live/Frugal/Full in the user choice of 32bit and 64bit. With this combination, it would cover just about every x86 in the world via a single ISO for a given PUP distro release.
I suspect, though, that WOOFCE/WOOFQ is not presently designed to allow this kind of PUP feature. But, I am not sure.
Hope this is a goodly explanation and somehow useful.
You merely download his ISO, burn/frugal it and boot. His splash screen give you the choice of which to boot.
Clever and nice. (Similar to what Knoppix has been doing for the past 9 years where it at boot time will boot.)
I had been hopeful that most PUP developers, by now, would have investigated and begun to present similar offerings instead of, separately, a 32bit distro version AND a 64bit distro version.
So, what so key about his offering is that instead of an ISO being one or the other, he gives the user one ISO that provides a choice to the user. Thus a user does not need to download a 32bit distro AND its 64bit companion. Instead, the users gets both built into 1 ISO.
The community is at a point where a developer who offers PAE 32bit and a 64bit PUP, today, would have followed his template to offer a single ISO for Live/Frugal/Full in the user choice of 32bit and 64bit. With this combination, it would cover just about every x86 in the world via a single ISO for a given PUP distro release.
I suspect, though, that WOOFCE/WOOFQ is not presently designed to allow this kind of PUP feature. But, I am not sure.
Hope this is a goodly explanation and somehow useful.
-
stemsee
In fact, the ISOs I have offered, er offer only different kernel and their modules options, i486, i386/i686 are both 32bit and the 64bit kernel with modules.
The system is completely 32bit. The advantage is that with a 64bit kernel one can run some 64bit software for example Qemu can then boot a 64bit ISO in virtual machine. So it is not a true 32 or 64 bit choice. It is a 32 bit system with some 64bit compatibility. Jamesbond has recommended running a 32 bit puppy with a 64bit kernel, given the choice. But if you are going to be compiling stuff then the output may be confusing, unless you specify the arch at compile time.
Of course 64bit native pups can load 32bit libs for running 32bit software. How about adding 32 and 64 bit wine into to the mix as well!
Clearly it is a useful compromise that I have offered but with downsides.
A single puppy with true 32 and 64bit 'choice' would be almost double the size. But a 64 bit pup offering 32bit compatibility seems more likely to offer better user experience imo.
What is being offered here is different and seems similar to piggybacking one main sfs on top of another. Similar to 'underdogging' I think BK labelled it.
I will be interested to see your script learnhow2code.
stemsee
The system is completely 32bit. The advantage is that with a 64bit kernel one can run some 64bit software for example Qemu can then boot a 64bit ISO in virtual machine. So it is not a true 32 or 64 bit choice. It is a 32 bit system with some 64bit compatibility. Jamesbond has recommended running a 32 bit puppy with a 64bit kernel, given the choice. But if you are going to be compiling stuff then the output may be confusing, unless you specify the arch at compile time.
Of course 64bit native pups can load 32bit libs for running 32bit software. How about adding 32 and 64 bit wine into to the mix as well!
Clearly it is a useful compromise that I have offered but with downsides.
A single puppy with true 32 and 64bit 'choice' would be almost double the size. But a 64 bit pup offering 32bit compatibility seems more likely to offer better user experience imo.
What is being offered here is different and seems similar to piggybacking one main sfs on top of another. Similar to 'underdogging' I think BK labelled it.
I will be interested to see your script learnhow2code.
stemsee
-
learnhow2code
ah, well. so this is not a new thing at all. it was a fun idea i had when i was mixing isos, and by the time someone else pmd me to ask if it was possible, i thought it might be intriguing.stemsee wrote:In fact, the ISOs I have offered, er offer only different kernel and their modules options, i486, i386/i686 are both 32bit and the 64bit kernel with modules.
this is exactly how it works: two vmlinuzes, two initrds, two puppy sfs files.A single puppy with true 32 and 64bit 'choice' would be almost double the size.
thats an important distinction. i only know of one person who wants or needs full 32+64 in a single iso, and this thread is here in case there are more.But a 64 bit pup offering 32bit compatibility seems more likely to offer better user experience imo.
not sure, because while the script i have is designed to remix isos including the contents of the sfs, it is meant to load one per boot option, at least in the context of this thread.What is being offered here is different and seems similar to piggybacking one main sfs on top of another. Similar to 'underdogging' I think BK labelled it.
but for the idea in this thread, there would be no editing of sfs files-- just copying (sort of like frugal) to the new iso, editing the isolinux config, and thats it. like you say- it doubles the size.
this is the script: http://murga-linux.com/puppy/viewtopic. ... 585#913585I will be interested to see your script learnhow2code.
however that version of it does more, and downloads two 32bit isos.
to make the 32+64 version, i took version 0.4 (linked to just now) and changed the refracta url from the 32 bit download to the 64bit one.
so it put together 32-bit puppy and 64 bit refracta, from the 32bit puppy isolinux installation / config (with options added from the 64 bit config.)
because of the way that puppy cds work layout-wise, it would be necessary to create a folder for the 64bit puppy or copy the 64 bit version to "live" on the cd, and edit the config accordingly.
or to give different names to vmlinuz and initrd and the sfs, and edit the config accordingly. but i havent done that.
IIRC, I was the suggester.
It just seemed like a good idea, a way to move Puppy forward. Right now we have two mainline TahrPup editions, both numbered 6.0.5. One is 32bit, one is 64bit, and differentiating between them gets awkward fast, especially with the newbs in Beginner's Help.
So, the idea -- one TahrPup or Slacko (or whatever) ISO, that boots as either 32bit or 64bit. So, now instead of asking "TahrPup 6.0.5 or Tahr64 6.0.5...?" we can ask, "did you boot the 32bit version or the 64bit version?" and the user (theoretically) should know the answer.
As a further thought -- Puppy supports the psubdir= switch. So, have 32 bit Puppy in "pup32" and 64bit in "pup64", and use psubdir=pup32 and psubdir=pup64 to get that going. Mind you, I'm far more familiar with Grub4dos than I am with isolinux so I'm not sure exactly how to do that -- but in theory it should work. There is apparently support within syslinux/extlinux/isolinux for a menu of some sort -- see here -- I'd suggest a text-mode setup that looks something like this to the user...
...as an aside -- why recommend the "without Pupsave" (which we now confusingly call "RAM Mode") option for firstboot? It seems cleaner to me. Sorry, I can't explain better than that.
It just seemed like a good idea, a way to move Puppy forward. Right now we have two mainline TahrPup editions, both numbered 6.0.5. One is 32bit, one is 64bit, and differentiating between them gets awkward fast, especially with the newbs in Beginner's Help.
So, the idea -- one TahrPup or Slacko (or whatever) ISO, that boots as either 32bit or 64bit. So, now instead of asking "TahrPup 6.0.5 or Tahr64 6.0.5...?" we can ask, "did you boot the 32bit version or the 64bit version?" and the user (theoretically) should know the answer.
As a further thought -- Puppy supports the psubdir= switch. So, have 32 bit Puppy in "pup32" and 64bit in "pup64", and use psubdir=pup32 and psubdir=pup64 to get that going. Mind you, I'm far more familiar with Grub4dos than I am with isolinux so I'm not sure exactly how to do that -- but in theory it should work. There is apparently support within syslinux/extlinux/isolinux for a menu of some sort -- see here -- I'd suggest a text-mode setup that looks something like this to the user...
Code: Select all
TAHRPUP 6.0.5 ISO
Boot 32bit TahrPup (Default)
Boot 32bit TahrPup without Pupsave
Boot 64bit TahrPup for newer hardware
Boot 64bit TahrPup without Pupsave
If booting Puppy for the first time, it's best to choose the "without Pupsave" option that best fits your hardware. If you cannot decide, wait 30 seconds, and 32bit TahrPup will be booted with Pupsaves (session persistence) enabled.-
learnhow2code
i can confirm this.starhawk wrote:IIRC, I was the suggester.
i think of it as a good move for a custom pup that doesnt mind being twice the size-- because thats the cost of a full 32+64 bit option. granted you can still fit both on a cd if you start with tahr.It just seemed like a good idea, a way to move Puppy forward.
definitely agreed on the merits, though some users (probably most) will prefer having an iso half the size.So, now instead of asking "TahrPup 6.0.5 or Tahr64 6.0.5...?" we can ask, "did you boot the 32bit version or the 64bit version?" and the user (theoretically) should know the answer.
im only doing this with isolinux because thats whats already on the isos that im editing. i never actually "install" a bootloader, i just use the genisoimage options for isolinunx and repackage one of the ones from the source isos.As a further thought -- Puppy supports the psubdir= switch. So, have 32 bit Puppy in "pup32" and 64bit in "pup64", and use psubdir=pup32 and psubdir=pup64 to get that going. Mind you, I'm far more familiar with Grub4dos than I am with isolinux so I'm not sure exactly how to do that --
any other bootloader would add an extra (very tedious and experimental) step, but i know some people here are more up to it (if they like.)
thats a fine menu, and i agree that being explicit about pupsave is better (and i guess they used to do that with the menus in early versions.)I'd suggest a text-mode setup that looks something like this to the user...
Code: Select all
Boot 32bit TahrPup (Default) Boot 32bit TahrPup without Pupsave Boot 64bit TahrPup for newer hardware Boot 64bit TahrPup without Pupsave
-
gcmartin
On your prior post, I want to comment on a couple items there.
ISO size: Over the years there has been MUCH TO MUCH confusion among membership. Some actually feel that the ISO size is the SIZE of the system. Some feel that ISO size means degraded performance. Some feel ISO chews up their RAM. Some feel ...
ONLY the Developers seemingly have a consistent understanding that ISO size is merely the size of the download that the user brings down to create a Live/Frugal/Full use on the desired PUP.
This lack of understanding in the member population is a source of grief from time to time.
32bit & 64bit versions of a given distro release
For some/many in this forum, they will download, test, and use BOTH 32&64bit versions of, say SLACKO or TahrPUP or ... They do so for a variety of personal reasons, some of which may surround the fact that they have both kinds of PCs at home OR some of which surround the understanding of the "architecture" that a given PUP uses (all PUPs do not have same libs/folder structs) OR ...
In these cases, the user is downloading "double" ISOs for a given breed. A combined ISO is not an out of the question step and has the potential of providing better feedback to developers and members from time to time.
Summary
@Learn2code, thanks for opening this discussion. And thanks to @StarHawk too for his discussion with you. This thread is opening our eyes a bit more and has the potential of benefit to both users and developers, alike. Matching into our future we may find a growing number of members who would download a combined ISO as their 1st choice.
A decade ago, members were still booting 128MB RAM PCs which we dont discuss anymore. A decade from now we will not be talking about 32bit PCs as our discussions will be centered...as least until Quantum technology invades use.
Hope this is helpful.
ISO size: Over the years there has been MUCH TO MUCH confusion among membership. Some actually feel that the ISO size is the SIZE of the system. Some feel that ISO size means degraded performance. Some feel ISO chews up their RAM. Some feel ...
ONLY the Developers seemingly have a consistent understanding that ISO size is merely the size of the download that the user brings down to create a Live/Frugal/Full use on the desired PUP.
This lack of understanding in the member population is a source of grief from time to time.
32bit & 64bit versions of a given distro release
For some/many in this forum, they will download, test, and use BOTH 32&64bit versions of, say SLACKO or TahrPUP or ... They do so for a variety of personal reasons, some of which may surround the fact that they have both kinds of PCs at home OR some of which surround the understanding of the "architecture" that a given PUP uses (all PUPs do not have same libs/folder structs) OR ...
In these cases, the user is downloading "double" ISOs for a given breed. A combined ISO is not an out of the question step and has the potential of providing better feedback to developers and members from time to time.
Summary
@Learn2code, thanks for opening this discussion. And thanks to @StarHawk too for his discussion with you. This thread is opening our eyes a bit more and has the potential of benefit to both users and developers, alike. Matching into our future we may find a growing number of members who would download a combined ISO as their 1st choice.
A decade ago, members were still booting 128MB RAM PCs which we dont discuss anymore. A decade from now we will not be talking about 32bit PCs as our discussions will be centered...as least until Quantum technology invades use.
Hope this is helpful.
-
learnhow2code
gc: part of the reason for the "confusion" is theyre not coming to the wrong conclusion, theyre just off on a couple points.
true: the iso size != the size of the system. however:
* the boot time is sometimes affected when more than one sfs is loaded
* the download size is affected
* the time to write the iso to cd or dvd (or usb) is affected
* the time to remaster the iso is affected (though not too too much.)
in short, almost everything they think a larger iso would affect is affected.
(but not always.)
the wish to stay away from larger isos is far from baseless.
i agree that people should consider the merits of a 32+64 iso and i appreciate your feelings about it, i was curious if anyone else thought it was a good idea. but i consider the iso size to be a legitimate part of the cost analysis-- the full 32+64 bit iso is for people who are more interested in the flexibility than the considerably smaller iso.
ive been analyzing a number of isos lately, and i can tell you, im happier to do it on half-size isos, every time.
true: the iso size != the size of the system. however:
* the boot time is sometimes affected when more than one sfs is loaded
* the download size is affected
* the time to write the iso to cd or dvd (or usb) is affected
* the time to remaster the iso is affected (though not too too much.)
in short, almost everything they think a larger iso would affect is affected.
(but not always.)
only the developers have any reason to maintain a complete understanding of it.ONLY the Developers seemingly have a consistent understanding
the wish to stay away from larger isos is far from baseless.
yes, but since they are mostly right, theres no reason the user should spend too much time or resources on an iso that is larger than they want.This lack of understanding in the member population is a source of grief from time to time.
i have one. i use it for printing. the others dont have parallel ports, and i like the printer.A decade ago, members were still booting 128MB RAM PCs which we dont discuss anymore
i agree that people should consider the merits of a 32+64 iso and i appreciate your feelings about it, i was curious if anyone else thought it was a good idea. but i consider the iso size to be a legitimate part of the cost analysis-- the full 32+64 bit iso is for people who are more interested in the flexibility than the considerably smaller iso.
ive been analyzing a number of isos lately, and i can tell you, im happier to do it on half-size isos, every time.
-
gcmartin
I think anyone would agree with the points your share. I hope that is obvious to almost everyone. But, in my experiences I am not sure that they are thinking about that.
Here's IMO a view. Its not everyone's view. You may have noticed from time to time members calling a contribution as being filled with bloat. Years ago I seem to remember someone saying that about one of @Pemasu's distro. The fact is the particular distro in question was larger than some other PUPs and the user failed to see (or neglected) that the author posted that HIS distro met his needs, merely. His work was beautiful proofs of what could be done for an easy to use PUP. But because it did not match a member's view, it was mis-labeled, IMHO. Each distro developer is attempting to present a GEM that matches what they feel the community may want in a desktop system. But, they, like us, have a view which may/is slightly different from other developers.
Sometimes, more often than I can count, members judge a distro's behavior and performance by looking at the ISO size.
Let's hope that in today's world more members are better understanding that ISO size is not a good measure of either performance on one's machine or value in content of the developer's contribution.
Your contribution should not be trashed for its size, rather it should be measured by its performance and behavior when running.
Most members was a distro that finds all of the system's hardware usefully, is stable, and has at a minimum the Menu with most of the standard items we have seen in the generations of PUPs. Some PUPs are faster than others, as seen traditionally.
I remember FATDOG5 and Lighthouse64 being one of the early PUPs which was phenomenally faster on 2 of my PCs than the, then, normally fast PUPs (faster than most full install distros).
Size is NOT performance. It never was.
Again, I agree with the obvious reasons you feel most member think. I believe they are aware of that, but, some might continue to mistake that there is a performance relationship to size.
Hope that this makes some sense.
Looking forward to the GEM you have been working toward.
Here's IMO a view. Its not everyone's view. You may have noticed from time to time members calling a contribution as being filled with bloat. Years ago I seem to remember someone saying that about one of @Pemasu's distro. The fact is the particular distro in question was larger than some other PUPs and the user failed to see (or neglected) that the author posted that HIS distro met his needs, merely. His work was beautiful proofs of what could be done for an easy to use PUP. But because it did not match a member's view, it was mis-labeled, IMHO. Each distro developer is attempting to present a GEM that matches what they feel the community may want in a desktop system. But, they, like us, have a view which may/is slightly different from other developers.
Sometimes, more often than I can count, members judge a distro's behavior and performance by looking at the ISO size.
Let's hope that in today's world more members are better understanding that ISO size is not a good measure of either performance on one's machine or value in content of the developer's contribution.
Your contribution should not be trashed for its size, rather it should be measured by its performance and behavior when running.
Most members was a distro that finds all of the system's hardware usefully, is stable, and has at a minimum the Menu with most of the standard items we have seen in the generations of PUPs. Some PUPs are faster than others, as seen traditionally.
I remember FATDOG5 and Lighthouse64 being one of the early PUPs which was phenomenally faster on 2 of my PCs than the, then, normally fast PUPs (faster than most full install distros).
Size is NOT performance. It never was.
Again, I agree with the obvious reasons you feel most member think. I believe they are aware of that, but, some might continue to mistake that there is a performance relationship to size.
Hope that this makes some sense.
Looking forward to the GEM you have been working toward.
-
Sailor Enceladus
- Posts: 1543
- Joined: Mon 22 Feb 2016, 19:43
To add to the excellent points learnhow2code mentioned about size/performance: I know that at least with PUPMODE 5, it puts the whole sfs into ram unless you specify pfix=nocopy (then it will only grow as needed). Now say you make the Slacko 6.3 sfs files uncompressed, which is about 720MB, and you have a 1GB RAM machine, you won't have much breathing room because it won't delete portions of the sfs in RAM when you need more, the entire 720MB will all be stuck in cache (yellow in htop) so you'll only have at most 280MB for user activities, which will probably freeze the system if you open the browser and play a longer youtube video. I recommend 2GB RAM (or 1GB + 1GB swap) if you see over 500MB for all the loaded files combined in the ISO.gcmartin wrote:ISO size: Over the years there has been MUCH TO MUCH confusion among membership. Some actually feel that the ISO size is the SIZE of the system. Some feel that ISO size means degraded performance. Some feel ISO chews up their RAM.
-
learnhow2code
to respond to gc again, and certainly without abandoning any of the points i already made, i will say that i wholeheartedly agree that you cant rate bloat just by iso size. bloat is a word to be used in frustration and disgust, when someone has carelessly (or inconsiderately) left you with something pointlessly oversized.
most of the larger puppies are oversized because theyre designed to cater to the person that wants whats there-- thats not bloat, that is just "more puppy to love." if you spend a good amount of time getting your puppy/setup/etc down to greyhound racing suitability, then of course you will decide against such larger puppies.
you may even think or refer to that entire category as "bloat," but its too bad-- because some of those puppies are still fast enough on modest pc specs. case in point i had a p2 or p3 without enough ram to boot puppy under ordinary conditions, but i managed to install debian wheezy on it, and run it with fluxbox. is there a puppy that runs faster than that? probably-- if you unsquash the sfs to the hdd, and rely on binaries that are much older-- which you could achieve by installing debian 6 or even 5.
there are lots of things you can do to make gnu/linux faster, like fitting it into ram, using older (more vulnerable) binaries, or simply sticking with a very lightweight window manager. the number one optimization i use is running icewm instead of xfce or lxde, and puppy does similar with jwm and rox-- very fast programs for a very fast distro.
if you want to define bloat as "anything youre not using that could be removed," chances are most puppy users have some of that-- including many that dont need to worry about it.
i used to run tinycore, and finally decided that fiddling with the packages wasnt worth the fiddling-- this from someone who already dropped their brand new 8gb usb (smallest one you can easily get these days, if you want quality from a retail outlet) with their own custom 0.95 gb iso dd'd to it. i really didnt need that one, i was just showing it off. perhaps its around, i have another usb i can put it on.
you know one thing you can learn from using a "bloated" distro? how to more efficiently remove bloat
but sometimes it becomes a sort of p***ing match, which is what happens when geeks compete sometimes. i wont pretend that everyone here is friends with everyone else, but this is one of the least nasty, least spiteful forums (certainly compared to ubuntu forums) and if you judge a distro, its better to do it fairly and accurately. for that, i recommend the advice from gc-- dont judge too quickly on a single metric.
most of the larger puppies are oversized because theyre designed to cater to the person that wants whats there-- thats not bloat, that is just "more puppy to love." if you spend a good amount of time getting your puppy/setup/etc down to greyhound racing suitability, then of course you will decide against such larger puppies.
you may even think or refer to that entire category as "bloat," but its too bad-- because some of those puppies are still fast enough on modest pc specs. case in point i had a p2 or p3 without enough ram to boot puppy under ordinary conditions, but i managed to install debian wheezy on it, and run it with fluxbox. is there a puppy that runs faster than that? probably-- if you unsquash the sfs to the hdd, and rely on binaries that are much older-- which you could achieve by installing debian 6 or even 5.
there are lots of things you can do to make gnu/linux faster, like fitting it into ram, using older (more vulnerable) binaries, or simply sticking with a very lightweight window manager. the number one optimization i use is running icewm instead of xfce or lxde, and puppy does similar with jwm and rox-- very fast programs for a very fast distro.
if you want to define bloat as "anything youre not using that could be removed," chances are most puppy users have some of that-- including many that dont need to worry about it.
i used to run tinycore, and finally decided that fiddling with the packages wasnt worth the fiddling-- this from someone who already dropped their brand new 8gb usb (smallest one you can easily get these days, if you want quality from a retail outlet) with their own custom 0.95 gb iso dd'd to it. i really didnt need that one, i was just showing it off. perhaps its around, i have another usb i can put it on.
you know one thing you can learn from using a "bloated" distro? how to more efficiently remove bloat
but sometimes it becomes a sort of p***ing match, which is what happens when geeks compete sometimes. i wont pretend that everyone here is friends with everyone else, but this is one of the least nasty, least spiteful forums (certainly compared to ubuntu forums) and if you judge a distro, its better to do it fairly and accurately. for that, i recommend the advice from gc-- dont judge too quickly on a single metric.