Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
Fedora Core 4 Test 1 slipsFedora Core 4 Test 1 slipsPosted Feb 24, 2005 6:15 UTC (Thu) by jd (guest, #26381)Parent article: Fedora Core 4 Test 1 slips I'm impressed by the Fedora team's dedication to using modern technology and advanced optimization techniques. Does this mean that we'll start seeing code compiled for the Pentium III, Pentium 4 or Pentium M? That would be one way to make use of advanced optimization techniques GCC already has. i686 is the Pentium II and the only programs compiled for it are the kernel, glibc and openssl, although I strongly suspect other programs would benefit. Fedora recognizes the i786, which is the Pentium III, but supplies no binaries for that architecture. The Pentium 4 (I guess the i886) is not recognized by any of the scripts or apps dealing with architecture. For example, if you told the box it was Pentium4, yum would fail as it wouldn't have any idea that it could use any ix86 RPM for that architecture. My biggest gripe with Fedora and Red Hat is this amazing belief that ext3 is the only filesystem on the planet. Whatever happened to XFS? JFS? Reiserfs? Reiser4? If too many options would confuse a novice, have a toggle button that switches to and from "expert mode" or something. It is a fatal mistake of any company to pursue a "not invented here" policy. Actually, make that the second-biggest mistake. The biggest is that they don't support enough hardware. They already patch the kernel, so it's not as if they would be doing anything arcane. Adding madwifi and other unofficial & not included drivers would go a long way to making Fedora an instant hit with newbies to Linux. One thing you do NOT tell a newbie to do is to configure and compile their own Linux kernel. Not unless you are into serious S&M. Finally, Fedora and fan-groups need to be a bit more organized and work together. ("Such an alien concept" he says, voice dripping with sarcasm. Or was it butter?) You have Fedora Core, Fedora Extras, Freshmeat, DAG, CCRMA, numerous other collections and plenty of Open Source projects that never get into collections at all. Not all will work with Yum, those that do usually don't have a mirror list that will, prioritization doesn't exist, few archives or projects are signed (and MD5 is broken anyway), duplication of effort is phenomenal and with no coordination, there's no way of knowing how the RPM version tags relate to each other. I have seriously considered whether it would be worth just mass downloading all the SRPMS from these sites and building a mega RPM collection that resolves all these issues, once and for all. Unfortunately, I woke up a little while later.
(Log in to post comments)
Fedora Core 4 Test 1 slips Posted Feb 24, 2005 6:41 UTC (Thu) by p9ing (guest, #1561) [Link] There are xfs, jfs, reiser, modules in the update kernel RPMS at least. I can't recall whether they are there at install time.
FC3 is the best hardware support I've seen since 7.2.
DAG claims that not all repositories "play nice" together, but several but not all of them are merging source trees, making the RPMS interchangable -- with yum.
Sorry, I just don't get where you are coming from.
Filesystems and repositories Posted Feb 24, 2005 7:58 UTC (Thu) by jmalcolm (guest, #8876) [Link] Fedora kernels support all the major filesystems through modules. If the initrd.img loads the modules for your filesystem it will boot Fedora fine. This is true at install time as well. I have more than one Fedora system using XFS. I can RPM a stock Fedora kernel and reboot without problems.
It is true that only Ext3 (and Ext2) is available for new installs though. This is something I do not like about RHEL/Fedora. I believe there is a conflict between SELinux and the other journaled filesystems but that might be changing.
http://66.102.7.104/search?q=cache:_F6n9RZGrZUJ:https://w...
As for repositories...there seems to be a move to try and unify the major RPM providers.
Fedora Core 4 Test 1 slips Posted Feb 24, 2005 10:33 UTC (Thu) by nedrichards (subscriber, #23295) [Link] Yes the 'expert mode' for that is calling the installer with 'linux xfs' 'linux jfs' 'linux reiserfs' etc. I've always run my fedora w/ XFS and have had 0 problems.
Fedora Core 4 Test 1 slips Posted Feb 24, 2005 7:36 UTC (Thu) by shalem (subscriber, #4062) [Link] Please people stop whining about having optimised packages for your cpu, does windows come with 6 different versions?
And if you whine at least know what you're talking about, the i686 family started with the pentium pro, then came along the pentium 2 which was a pentium pro with the internal cache removed and mmx added, the p3 was again just a souped up pentium pro, this is the REAL i686 family.
The p4 otoh is a whole new design and the new p4's (presscots) the ones with the model numbers are again a whole new design (yet still called p4, to hide that they are actually slower then the old p4's), this is for some reason still called the i686 family afaik.
And the pentium mobile is a pentium pro based design with quite some changes to it, so basicly again a new beast.
So we have 4 different beasts to deal with (counting only intel):
Also you really need to make a difference between which instructions are used and for which cpu the code is optimised. All binaries in FC3 are optimised (instructionscheduling wise) for the (pre-prescot) P4, this is doen because this is the most widely used processor now a days and because P4 optimised code also runs pretty good on Ppro/2/3. AMD cpu's really don't mind that much what you feed them, they perform descent with just about any code.
Beside the optimal instruction scheduling, you also have difference between cpu models in available instructions, this is where the i386 and i686 rpm's come into play. i386 rpms use only 386 instructions (needed for via epia systems), but their (much more important) instruction scheduling is optimised for the pre-prescot P4.
For the few cases where the few normal instructions only available in newer CPU's do make a difference there are seperate RPM's.
Programs which benefit from special instructions like mmx and sse usually contain both normal and mmx/sse versions of the code in question and determine the availability of mmx/sse runtime.
Anyways this discussion has been had over and over on the fedoral-devel mailinglist, and the default answer is, if you believe optimalisation for your specific cpu helps then:
Fedora Core 4 Test 1 slips Posted Feb 24, 2005 7:53 UTC (Thu) by davej (subscriber, #354) [Link] > The biggest is that they don't support enough hardware.
Oh please, if it compiles, and isn't a steaming turd, chances are its enabled in Fedora kernels.
> They already patch the kernel, so it's not as if they would be doing
We're not patching it /that/ much. Asides from a handful of features like exec-shield, Xen and a handful of other bits there's really not that much in there these days. FC4 is currently around 50 or so patches off the top of my head, and I'm working to get this even lower by the time FC4 ships. FC3 is somewhat higher, because its based on 2.6.10, and has a bunch of fixes from 2.6.11rc added to it. (After a rebase to 2.6.11, it'll drop off to around 40-50 or so again).
> Adding madwifi and other unofficial & not included drivers would go a
And what happens when upstream then implements something completely different, and I put out an update kernel ? Users get screwed by the change. Merging drivers & subsystems into vendor trees is *not* the way to go. The only drivers added to the Fedora kernel over the last year or so have been speedtouch, and the ipw wireless drivers. Speedtouch was merged so that it could be used out of the box on FC3 (as it was getting merged upstream at the same time, but hadnt yet appeared in a released kernel).
This stuff needs to be upstream. Read the Fedora manifesto. It clearly states that we strive to be as close to upstream as possible in the kernel we ship. Having a vendor tree filled with random versions of various drivers pulled from here there and everywhere is the road to madness.
I've seen this happen firsthand - We merge a driver, a bug is found, we scratch our heads, ask the upstream developer to take a look - "not interested as its a red hat kernel and there are other patches there".
That model is doomed. The only way this can work is by getting as much as
Fedora Core 4 Test 1 slips Posted Feb 24, 2005 11:46 UTC (Thu) by arafel (subscriber, #18557) [Link] >Oh please, if it compiles, and isn't a steaming turd, chances are its>enabled in Fedora kernels.
You're getting dangerously close to "it builds? ship it!" there. ;-)
Fedora Core 4 Test 1 slips Posted Feb 24, 2005 8:37 UTC (Thu) by nix (subscriber, #2304) [Link] I'm impressed by the Fedora team's dedication to using modern technology and advanced optimization techniques. Does this mean that we'll start seeing code compiled for the Pentium III, Pentium 4 or Pentium M? That would be one way to make use of advanced optimization techniques GCC already has.Your belief that advanced optimization techniques imply compilation for a particular CPU is... peculiar. Most of the improvements in GCC 4.0 are infrastructural, and while they should lead to a faster compiler that's much better at optimizing, that improvement will be visible to everyone no matter what their CPU, not just people with new CPUs. (In fact, the largest single problem with GCC's optimization on IA32 right now is probably the tangled intertwined mess that is the regalloc/reload passes; but so far no attempt to rewrite those monsters has succeeded.) The largest improvements with GCC 4.0 are invisible: right now, the focus is on getting the tree-ssa optimizers to carry out the same optimizations as the RTL ones did, so the RTL optimizers can be ditched --- well, right now the focus is on stabilization for the GCC 4.0 release, but you know what I mean. (That's not to say that there aren't a whole heap of nifty new optimizations, too. But getting rid of RTL optimizers that try to build palaces using individual grains of sand is I think more important.) (Joe, feel free to correct me if I'm talking nonsense, which I probably am.)
Fedora Core 4 Test 1 slips Posted Feb 24, 2005 10:13 UTC (Thu) by james (subscriber, #1325) [Link] Does this mean that we'll start seeing code compiled for the Pentium III, Pentium 4 or Pentium M? We already do. Practically all of Fedora Core 3 for i386 is compiled with Pentium 4 optimisations (which also work well on Athlons). Where code can benefit from the (few) extra instructions introduced between the 386 and the Pentium Pro, then you'll get separate i686 and i386 packages. I understand that the standing offer is to compile using the extra instructions if someone can show rigorous, repeatable benchmarks that prove it would be beneficial (which rules out "Gentoo feels faster"). I've never seen anyone actually deliver those...
|
|||||||||||