[CentOS-devel] Status of CentOS 5 for the i586?

Tomorrow if there's time in town I'll see about fetching the rhel6
kernel and playing with it. It'd be nice to know ahead of time if it
compiles cleanly for i586. I'll also play with build scripts in the
upcoming week.

On 6/5/11, Dmitry E. Mikhailov <d.mikhailov at infocommunications.ru> wrote:

>
> Do we really need it after all? There are doubts.
>

>From what I gather from the wiki page, it's not just for ancient
things like the i586, but older VIA CPUs. I wouldn't know for sure
because I don't have any of these :( In addition, it's kick-starting
alt-arch support for things like ALPHA, SPARC, I64, etc. (Maybe.)


> mesa-libGL-6.5.1-7.8.el5.i386.rpm	26-Apr-2010 19:59 	9.6M
> ...
> It's built with i386 arch tag so it shouldn't need rebuild.

The C5 on the Pentium project page notes that Mesa was built with
-ffast-math, which apparently (?) doesn't play nice with i586. If this
is incorrect, that's great, because it means less headache for the
package builders.

http://wiki.centos.org/Projects/CentOS5PentiumSupport


> Even less if a script does a:
> 1)fdisk on a target drive
> 2)mkfs.ext3
> 3)mount
> 4)cp -aR /installed/and/ready/filesystem/converted/to/i586/already
> /on/a/formatted/hdd/mount
> 5)grub-install

This looks like it might save some time; I'll give it a whirl when I
get my USB hard drive adapter tomorrow.


> If hardware is alive and in a box already ;-)

I think that if it's not alive then people aren't going to go looking
for it. Then again, being a computer necromancer has its moments.


> I was doing 'rpm -e' until I got something like 730MB. Was hard to go
> further.
> Minimal install gives you various crap like irda-tools for example. Kudzu
> depends on a haldaemon. The haldaemon depends on dbus. The latter two bring
> about 50MB of unneeded libs with them AFAIR. But I like kudzu. There's a
> lvm2-monitor from lvm2 package. I don't need one, but mkinitrd depends on it
> and we need mkinitrd to update kernels. You could rip sendmail, but you'd
> lose LSB compliance. And remember, it's a wrong way.
>
> This way we'd end up building our own, another Linux distro for firewalls.
> But
> we're here because of upstream compliance and upgradeability to a more
> decent
> box if need arises WITHOUT ANY MIGRATION/REINSTALL.

I dunno; when I get this thing to boot natively into an installer I'll
let you know how much it takes to do a minimal install. I think the
way I have it now it's about 500MB (?) of packages, which is still
excessive to me but works. (Of course, keeping in mind this machine
came with a 480MB hard drive before I swapped it for a 30GB drive...)


> 1)wget a_new_kernel_src.rpm
> 2)rpm -i
> 3)patch -pX /on/a/rpm/SPEC/file </to/include/our/patch
> 4)rpmbuild
> wait until a gazillion of individual patches are applied
> (offtopic - this time I won't be against RHEL6 prepared-and-intergrated
> kernel
> source tree)
> 5)copy a built RPMs where needed
> 6)rebuild repo metadata

Exactly! That's what I hope to have set up soon. As it is, I already
have the .patch for the spec, so wrapping it in a script shouldn't be
too bad. The only thing I add is running it through Mock--I like
things being separated into little compartments. The end result is the
same.


> On a lightly loaded server (4-core Q6600, SCSI disk subsystem) it doesn't
> take
> enormous time.

Remember, I'm the guy with the i586s. No quad-cores for me. :P But
you're right, it doesn't take too long, and updates--and hence
rebuilds--are few and far between.


> It takes 650MB on my current desktop. Why so much?
> But (to compare) I've seen (on a windoze machine) a Google Chrome with 11
> tabs
> open taking 1100MB. Nobody seems to care. They install 4GB just because it's
> cool. Then run 32bit OS while asking stupid questions like 'why it doesn't
> see my full 4gig of ram' but NOT asking 'why I need 4gig of ram' in the
> first
> time.

Minor offtopic: this is something that disappoints me. It used to be
that folks went to college to learn how to write programs leaner and
meaner and make them fit into less RAM, because we had less RAM then.
Now with RAM so cheap, we have a ridiculous amount of it in
desktops--my new LAPTOP has more memory than any desktop I've owned to
date, and it's fairly low-end--so here come the programs
*COUGH*WINDOWS*COUGH* that eats up ridiculous amounts of memory just
because we have it. Ahh, progress.


> It would take ages to install anyway. So no one would use it anyway. Then
> why
> fixing?

I'm the person that believes an operating system should allow a person
to shoot themselves in the foot if they try something dumb (like
installing on 64MB of RAM). If someone thinks they're smarter than the
OS--which, usually, they're not--let them try it. If they're the
learning type, they'll learn not to do it again, unless they're like
me, in which case they're utterly hopeless and will continue to do
dumb things just for the heck of it.


> 2 sticks of 32MB each from 486sx? Can't believe it! 4MB it much more
> plausible.

Might've been the P133 then--it's been a few years...it was either the
486sx, the 386, or the P133. Those were the only SIMM boxes I
remember.

Cheers,
Cody Jackson