On Mon, 21 Oct 2002, Andrew Smith wrote: >> Actually, you're wrong. The architecture field present in the >> RPM filename, and header indicates the "instruction set" in use >> by the binaries inside the package. It means that you need a >> machine capable of that instruction set, or higher in order to >> install and use the package. > ><snip> > >OK - I've cut it all out so as not to waste bandwidth repeating >that very useful response - but I'll certainly say that has to be >the best reply to an e-mail that I have ever received! > >Interesting if you take that to the next step - it means that there >are NO extra useful instruction or optimisations in a 486 or a >Pentium (586) procesor over a 386 processor i.e. Intel's only >enhancements from 386 to Pentium (586) was increased processor >speed and internal performance. Not only that - but there are also >no instruction optimisations in the 486 and Pentium (586) processors >over the 386 (OR the compiler developers couldn't be bothered >implementing them coz the optimisations are not worth the trouble) Well, there are new instructions in i486, and i586, however most of them just are not useful in general purpose code. They're more useful for special purpose code. I'd have to doublecheck to see what if any instructions new to i486 are used at all. BSWAP and CMPXCHG are two new ones that come to mind on i486, but again, they're not typically very useful in general code, and I don't believe that gcc uses either. The Pentium only adds CMPXCHG8B, and possibly a few others that I don't recall off the top of my head as my brain is in Athlon mode lately. That instruction IIRC is an optional one in the instruction set, and again isn't generally useful. BSWAP can be used in a crafty way the instruction wasn't intended for, in order to provide more 16bit registers available in code, by swapping the upper and lower portions of a 32bit register thus making the upper 16bit portion of a 32bit register useable when not needing 32bit registers in a fragment of code, but where having more 16bit ones would be beneficial. For example, using a 16bit integer in AX, then doing a BSWAP and now AX is in the upper 16bits of EAX, and you can reuse AX, then BSWAP back when you want to use the other half again. It's a trick that was once useful in days gone by, however I'm not sure how useful it is on any modern processors. I don't believe gcc uses this anywhere, and I'm not sure it would be useful if it did nowadays. I'll leave that for someone who is more familiar than I with the innards of gcc. >>>I can think of a lot of reasons why the i386 kernel was not >>>there - but maybe one would be that general RedHat support for >> >> Ultimately it was a disk space decision, as stated previously in >> the thread. The presence of an i386 kernel however would not be >> endorsement of "support" for i386/i486 processors. Our box, and >> documentation list the minimum system requirements for support. >> Any machines or hardware that do not meet the requirements, while >> unsupported, may or may not work, and may or may not have a >> kernel to use out of the box. > >Yes - well as stated previously - disk space is not an issue - it >was probably more likely someone was told to not put it on >(or whoever arranged the CD's contents needs to be fired and replaced) The availability of some free space on the final ISO images is not indicative of "free space" being available for the kernel. It's much more than disk space being there, it's also procedural, and focusing on what is important to get the distribution completed and shipped out the door. At some point free space was not available, and the decision was made to remove the i386 kernel to make it up. That decision wasn't made in the 11th hour, but rather likely sometime before that, although this is conjecture as I don't recall (or care) what the exact specifics were. They aren't terribly important either. The process of day to day modifying of packages leading up to distro release, can add or remove any number of megabytes of disk space to the distribution. It's entirely possible that some last minute mission critical change was needed that ended up freeing up 10Mb or whatever. Possibly the removal of MP3 software or somesuch. I've no idea, I'm just providing a random example to illustrate the point. In order to cram a kernel on there if and when space became available, we'd have to first care about the i386 kernel, and have it as a concern to watch out for in case some future process before final distribution caused space to become available. At that point in time adding an i386 kernel would require recompiling the kernel and invalidating any QA done on it. For what? It's impossible to trace the disk space changes from the point in time i386 kernel was removed until the final ISO's were shipped, but disk space was in fact the deciding factor - regardless of 10Mb or whatever being empty on the final ISOs. As one can likely understand, after removing the kernel, it was not a high priority to re-evaluate free CD space every 10 minutes to see if some other random last minute distribution change allowed an i386 kernel to fit. So anyone who offers forth the claim that there is space that could have fit an i386 kernel is looking at the issue through tunnel vision, and not through the processes, procedures, and priorities that put together a Linux distribution. In other words, the thought process is more like "Ok, we need space, lets kill the i386 kernel, ok it is killed." and forgotten. The people who are claiming there space that could have held it, are thinking of it like we should be instead doing: "Ok, we need space, lets kill the i386 kernel, ok it is killed. Now lets monitor every change we make from now until the final gold day, to see if any change we make allows space for the i386 kernel, and then we can put it back." After thinking about what I just said above, you can see how that thought that free space is available in the end perhaps, doesn't match the process or priorities involved. >>>older hardware is not as good as MS (RedHat seems to sometimes >>>drop support for old hardware that was supported in the previous >> >> Try to install Windows XP on an i386 or i486 computer and see how far >> you get with Microsoft support. > >My issue is that if there was a 386 kernel on the CD's it WILL work >on a 386 so basically you are stopping people who buy/download your >ISO's from running software on a machine that WILL work. There's no guarantee it would work on an 80386 at all. I'd be as bold to say that there is a very good chance it wouldn't work very well or at all on an i386, because there has been absolutely zero testing on 80386 hardware. Not to mention all of the drivers not being tested on such ancient hardware. The number of people who would actually try to install Red Hat Linux 8.0 on a real 80386 class machine, I can probably count on one hand, and those people are very capable IMHO of compiling their own kernel and hacking something up to meet their _very_ special needs which are very very far from general purpose. The same can be said for i486 class hardware (which we have not officially supported for 2 years). There are people out there, such as myself using an i486 for a firewall, or for a dumb X terminal or other low end use, but they're not the majority of users, and we're not really targetting our products at those people. Red Hat Linux is engineered to work on todays modern hardware, and as time goes on, the requirements to install Red Hat Linux will likely become higher and higher. As machines become more ancient, it becomes a larger waste of our engineering, tech support, development support, and QA and other resources to continue to support ancient hardware like i486. Some might argue that shipping it anyway, but "unsupported" would meet everyones needs, and not require any overhead on our part, but that isn't entirely true. We still have to build the stuff, consuming our buildsystem resources, our developer resources, and our QA engineers time, etc. and we'll still get bug reports from people regardless of wether or not we support it. We'll also get the "you ship it, you must support it" type of people. Any technical decision that we make, is generally based on what is best for our target market of users, and the hardware that they are using. I don't know about others, but I'd much rather see 10Mb of cool new useful software added to Red Hat Linux, than to keep around an unsupported i386 kernel on our CDs. Not to mention the problem of people installing i386 kernel and not having working hardware 3D acceleration because DRI does not work on i386 because it uses CPU instructions that aren't available on that CPU class. This has caused me numerous bug reports against XFree86 of DRI not working, but in every given bug report, it's never quite clear what could be wrong on the persons system until after I've expended a finite amount of my useful time on the problem that could have been spent elsewhere. Finding out after 2 hours of troubleshooting that someone is using an i386 kernel on a Pentium IV, and DRI isn't working because there aren't any DRI modules, is rather a PITA. Of course, it doesn't generally take 2 hours, but you get the idea. >Yes there is no point running KDE/Gnome on anything much below a >PIII 500 (I know that as a fact in earlier releases - a PII 333 >is too slow) but you do NOT need X to run a server - my DNS/mail >server is only a P90 and my router with over 450 lines of >firewall that runs quite a few other things (including a java >message server I wrote) is only a P166 and ... well it has >PLENTY of spare processor space: Certainly, and we support P90, so that's not a problem. Pentium CPU's are supported. >Yet they may fall into the "no kernel available" hole in the >future even though they are well able to run as a server. At some point in time they most probably will. And the minority of users still using those ancient systems at that point in time that we drop support for them and don't provide a kernel for them, can do like i486 users are doing right now, either stick with RHL 7.3, or build their own kernel. If we look at CD space percentagewise, I'm willing to bet the percentage of CD space an i386 kernel set consumes all around, is on the order of 2-3 magintudes larger if not more of the percentage of users using i386/i486 class machines. It could be argued that we should find 10Mb of more useful software that 95% or more of our userbase would benefit from, and drop the stuff that 0.001% of the userbase wants that isn't supported. >I have a 486 that used to be my mail/DNS server but has sat >there unused for about a year - but I know it is fast enough to >do that job (and it would get that job back if the current P90 >failed) I've got an AMD 486 here with 12Mb of RAM. I plan on putting RHL 8.0 on this machine and documenting it, as proof of concept that if you really want it to happen, you can do so. I'm positive I'll have no trouble getting it to work too. I don't plan on using it for anything, but rather just to document the experience and show the vast minority of i486 Red Hat Linux users, that if they are still hardcore about getting the distro to run on i486, they can. I don't think it's unreasonable to expect users to fiddle a bit by hand to get something like this working on hardware that is 7-8 or more years old. Don't forget also, that people wanting to do such, will likely get help from myself and others at Red Hat on this or other lists, just to show "it can be done" if you really want to. That is what this community is here for. For users to help users. And keep in mind also, I'm here because I'm also a user, not because I'm a Red Hat employee. The latter is just coincidence. ;o) On a different note... Has anyone try using a Radeon 8500 in an i486? ;o) Take care, TTYL -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer XFree86 maintainer Red Hat Inc. -- Psyche-list mailing list Psyche-list@redhat.com https://listman.redhat.com/mailman/listinfo/psyche-list
