Red Hat Fedora Core 4 Test 1 Now Available

krunchyfrog writes "The first test release of Fedora Core 4 is now available from Red Hat and at distinguished mirror sites near you, and is also available in the torrent. New features in Fedora Core 4 test 1 include previews of GCC 4.0, GNOME 2.10, and KDE 3.4, as well as support for the PowerPC architecture. Please file bugs via Bugzilla, Product Fedora Core, Version fc4test1, so that they are noticed and appropriately classified. Discuss this release on fedora-test-list. -- The BitTorrent link is already there."

Comments

Re:GCC Version

[Anonymous Coward]

I don't know what you mean by that makefile making bad code thing, but gcc 4.0 sports a new optimization infrastructure. I have been experimenting with it since October, and I found it to be far superior to 3.x. Also, the compilations times are reduced somewhat.On the whole I'm quite impressed by the improvements, though I'm not sure I'd base an operating system on a compiler which is not released yet...

Anyways, Gnome 2.10, Xen 2.0 and GCC 4.0 are quite enough reason for me to download FC4 Test 1 and try it out.

Re:KDE 3.4 translations

[Vo0k]

Honestly, I'm glad I learned English, comparing to translations.

Sometimes the translations are okay or nearly okay. Sometimes they are terrible. And worst if you get used to "native" version and then when translation appears, keyboard shortcuts are remapped to match new words. I LOATHE when suddenly aumix stops responding to Q for Quit and I must read help to see that now it's K as "Koniec" (and not W for Wyjdz, Z for Zakoncz, O for Opusc which are synonyms).
I feel thoroughly lost in "translated GIMP". Suddenly finding an option becomes tricky. "SOTA Chrome" becomes "Krysztal" while "Cristal" is being renamed to something yet different, and only by remembering the position in menu I'm able to guess where it is. Sure it's about "getting used to", but then some things are simply translated incorrectly and guessing their meaning in your native language is just impossible...

Learn English. It pays.

Hope they get more bugs sorted out before release.

[pklong]

Looking at the updates directory of core 3 there are gigs of updates in there. It didn't even install on my nVidia nForce system because of bugs in the SATA drivers in the 2.9 kernel. (It's fixed in 2.10 I believe.)

Installing the nVidia drivers (because shock horror I wanted 3D) froze then system on boot because of the rhgb red hat graphical boot thingy. The switch to udev caught me out here. Luckily I figured out what was happening and sorted it.

I also had weird sound corruption in some programs which I tracked down to arts. Turning the sound down in that sorted it but I can't find any kind of a config file, let alone a GUI application that sets a sound level which survives a reboot. I sorted it my adding an entry in rs.local.

Also why on earth don't they compile NTFS reading into the Kernel. (Captive NTFS would also be nice as an option...)

Sadly your average tech fiddler on the street would have given up with this pallava and installed Windows.

XP Installation went without a hitch and worked perfectly first time. It can even play MP3's out of the box ;)

So for all you Slashdotters out there who think a Linux install is easier than I Windows install, well it can be. Provided nothing goes wrong. Which is unlikely.

When will RPM-based distros change to .deb?

[z1d0v]

It seems that there are a lot of people starting to defend the use of the debian package for the easiness of dependencies treatment (and I'm not talking about debian folks like myself). So one might ask: will distros like Redhat/Fedora change the package manager in the future?

Since I don't use a RPM-based distro for a long time, I also feel the urge to ask: how is the dependencies treated nowdays?

Re:When will RPM-based distros change to .deb?

[Coryoth]

So you love Apt or yum. Great. Apt does not mean .deb. Apt can still do its normal great things using rpm formatted packages, so clearly the greatness comes from the tool, not the package specification.

The fuure of package maangers, like Smart, make this even clearer. Smart is like apt (but has better dep resolution algorithms) except it supports pluggable backends - that means currently Smart supports .deb, .rpm, and even slackware .tgz. It can manage those from apt repositories, yum repositories, urpmi repositories, re-carpet channels, whatever. You can even do a mix and match between formats and repository types if you want (though that, of course, can get messy).

The point is that package management and dependency solving are largely independent of package formats (as long as the format contains some dependency information). We can have a global package manager that works everywhere and doesn't care which package format it happens to be working with.

Jedidiah.

Re:KDE 3.4 translations

[anpe]

I wish I had mod points. You're right, both sides are needed.
Not just because of the importance of keeping languages alive
I just read an article that correlated the use of a local language (as opposed to english mostly) with the vitality of the local research.
That is, the more you use your own language for research the more your research field is "creative" in your country.