Fedora Core 4 plans announced

[Posted January 17, 2005 by corbet]

From:		Bill Nottingham <notting-AT-redhat.com>
To:		fedora-devel-list-AT-redhat.com
Subject:		Fedora Core 4
Date:		Fri, 14 Jan 2005 17:30:20 -0500

A Fedora Core 4 proto-schedule is available at:

http://fedora.redhat.com/participate/schedule/

Generally, it's 3 4-week test releases, with a release in early/mid May.

So, what's planned for Fedora Core 4? Here's what we're looking
at from the Red Hat side of things:

- GCC 4, if it's ready

  We're not planning on holding for it, but if it's out in a
  reasonable time, sure. Failing that, we're looking at making
  more of the FORTIFY_SOURCE and other gcc & glibc security extensions
  integrated, if at all possible.

- The usual new stuff - GNOME 2.10, KDE 3.4, Xorg 6.8.2,
   OpenOffice 2.0 (maybe), etc.

- Xen and Virtualization

  This starts by integrating the Xen kernel stuff, and going
  from there.

- SELinux Episode III: Revenge of the AVC

  Yet more targets in the targeted policy.

- Faster boot

  Eliminating redundancy and old cruft in the bootup process,
  starting GDM early if possible, using newer and faster
  udev codebases, and other related tweaks.

- Java

  More native-compiled GCJ stuff. Including Eclipse.

- Package management

  GUI integration of system-config-packages, yum, and friends.

- more networking changes

  Further integration of NetworkManager

- PPC support

  For your brand spanking new MiniMac, or the p655 under your
  desk.

- Extras at launch time. Or else.

  Hopefully, self explanatory. Could coincide with the move
  of some bits from Core to Extras. In fact, some of the
  stuff on this list of features may *be* in Extras.

Probably other stuff that I'm forgetting in here. I'm sure
more people can remind me.

Bill

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list

to post comments

GCC 4

Posted Jan 17, 2005 17:41 UTC (Mon) by danielos (guest, #6053) [Link] (8 responses)

It will not be of practical use until a 4.1 release, I fear.
I like it to be included on distros as beta compiler.

GCC 4

Posted Jan 17, 2005 20:21 UTC (Mon) by steven97 (guest, #2702) [Link] (2 responses)

What makes you think this? I can assure you, I'm quite happy with GCC 4 as it is developing now. Sure, there are some problems here and there, but nothing big really. SUSE, RedHat, and Apple are all already using GCC 4 derived compilers for serious work, and the number of serious bugs is going down each day.

I agree that GCC 4.1 will have fewer rough edges than GCC 4.0, but that is what you get with a x.0 release. But if you think about this as a distribution builder, the last thing you want is to release a GCC 3 based compiler in your beta distribution now. If that beta is the base distro that you build your enterprise release on, then you risk ending up supporting an old compiler infrastructure for the next five years. GCC 4.0 is radically different internally from GCC 3, so you do not want to have to do that. And Fedora is of course, in a way, a RHEL-beta-like product. So going with GCC 4.0 makes a lot of sense for Fedora.

GCC 4

Posted Jan 17, 2005 21:46 UTC (Mon) by yokem_55 (subscriber, #10498) [Link]

In addition, it is easier for binary based distro's to use the latest and greatest comilers since workarounds that are needed for building various packages are easily masked from everyone using those binaries. For source driven distro's like Gentoo however, the quality of the compiler is essential to the everyday health of the system, as everything is build by the user and unless the workarounds are already integrated into the build scripts, a newer compiler can wreak absolute havoc. Hence, gentoo, which is for the most part a bleeding edge distro, still uses the gcc-3.3 line of compilers by default for the 32-bit x86 arch.

GCC 4

Posted Jan 22, 2005 12:42 UTC (Sat) by danielos (guest, #6053) [Link]

Something user (not programmer) use to do is compiling the kernel, and there are a number of regression in this field that make gcc 3.3 better (and 2.95 better than 3.3). But this do not matter: as you said it's a beta.

What really could make think break is C++ changes that could break source compatibility: a lot of good work have be done it this area but there are some bug outstanding that, IMO, should be fixed for 4.0.0 release and are postponed for 4.1 instead. I repeat, IMO this policy is not very good, also, given the good work gcc developer are doing in these day for bug fixing, I guess that fix some parser bugs is not a so hard work. But steering comite state this changes are not possible now.

I use 4.0 myself, I don't see a lot advance. GCC 4.0 is the base architecture for a better optimization but a small part of this is done.

GCC 4 - C99 status?

Posted Jan 17, 2005 22:24 UTC (Mon) by tjc (guest, #137) [Link] (4 responses)

Does anyone know, is there a C99 status document for GCC 4.0 yet?

GCC 4 - C99 status?

Posted Jan 18, 2005 3:52 UTC (Tue) by havardk (subscriber, #810) [Link] (3 responses)

The status for the cvs trunk is here: http://gcc.gnu.org/c99status.html
As far as I know, there is no branch for gcc 4.0 yet.

GCC 4 - C99 status?

Posted Jan 18, 2005 17:03 UTC (Tue) by tjc (guest, #137) [Link] (2 responses)

Rats. I found that straight off, but I was hoping it was out of date. I'm longing for variable-length C99 arrays.

Thanks for the link though.

GCC 4 - C99 status?

Posted Jan 19, 2005 9:37 UTC (Wed) by steven97 (guest, #2702) [Link] (1 responses)

GCC does support VLAs.

GCC 4 - C99 status?

Posted Jan 19, 2005 18:25 UTC (Wed) by tjc (guest, #137) [Link]

GCC does support VLAs.

I was referring specifically to C99 variable-length arrays, not the GCC extension that has been around for some time.

According to the document linked above, the current status of of C99 variable-length arrays is "broken."

Fedora Core 4 plans announced

Posted Jan 17, 2005 23:34 UTC (Mon) by djabsolut (guest, #12799) [Link]

Nothwithstanding that Fedora is a "bleeding edge" distro, I do hope RH will release this without easily caught bugs like this.

Faster boot

Posted Jan 18, 2005 9:54 UTC (Tue) by climent (guest, #7232) [Link] (5 responses)

As long as gdm is not ready to accept a login before the ldap service is up and running, I am happy. Ubuntu guys got so greedy at FastBooting their distro that with a fairly slow ldap startup the login was failing.

So what can you do with a fast login screen that does not allow you to login?

Faster boot

Posted Jan 18, 2005 17:58 UTC (Tue) by brouhaha (subscriber, #1698) [Link] (1 responses)

Why should those of us whose logins do not depend on LDAP (but use LDAP for other things) be penalized? The default configuration as installed doesn't depend on LDAP for login, so it shouldn't wait for it either. If you reconfigure your system to need LDAP to login, you can reconfigure it to wait for the LDAP server to start also.

Faster boot

Posted Jan 20, 2005 3:49 UTC (Thu) by piman (guest, #8957) [Link]

Of course, ideally, the GDM start scripts would check to see if LDAP logins are being used and adjust accordingly, making everyone happy.

Faster boot

Posted Jan 18, 2005 18:26 UTC (Tue) by Ross (guest, #4065) [Link]

I wondered about dependency problems when I read the announcement. Couldn't
the X login programs or the libraries they use have some logic to retry a
few times if a directory service isn't responding? And when they do fail,
maybe they could show a different error message than for a authentication
failure.

Faster boot

Posted Jan 19, 2005 21:57 UTC (Wed) by Soruk (guest, #2722) [Link] (1 responses)

Oh dear. Why does this remind me of NT4, where the login prompt appeared before most of the services had started?

Faster boot

Posted Jan 20, 2005 7:32 UTC (Thu) by jeld (guest, #22397) [Link]

≤sarcasm> Because end-users are ~~stupid~~ impatient. So, everyone tries to start the nice GUI screen as fast as possible. Generaly this doesn't cause problems unless some overzealous geek tweaks his system into oblivion and then complaints that it doesn't work ≤/sarcasm>

SSH

Posted Jan 19, 2005 2:31 UTC (Wed) by gdt (subscriber, #6284) [Link] (2 responses)

My humble request would be for the SSH server's configuration to be tightened (no root login, restrict logins to a particular group, say "ssh").

The current configuration relies upon users choosing good passwords, and we know that 10% of users can't do that. The anaconda installer doesn't test the strength of the root password, so about 10% of installations by non-professional sysadmins can be expected to fall to intensive SSH scanning.

There should be some sysadmin action before an account's password is made accesable to scanners.

SSH

Posted Jan 20, 2005 20:56 UTC (Thu) by brouhaha (subscriber, #1698) [Link]

My humble request would be for the SSH server's configuration to be tightened (no root login

I disagree that this should be a default. I can sort of see why someone might want that, though I never would. But I routinely *depend* on the ability to SSH into a newly installed box as root.

restrict logins to a particular group, say "ssh"

That seems much more useful. If you had that feature, and you really didn't want to allow root login by ssh, you could simply leave root out of the ssh group.

SSH

Posted Feb 12, 2005 22:06 UTC (Sat) by mperkel (guest, #27861) [Link]

I strongly disagree. I always SSH in as root. I have no use for artificial restrictions and the mythology about running as root. I'm and expert and when I want to get real work done I don't want the OS restricting me. In fact - make of the servers I run only have a root user and nothing else.

If you don't know how to run as root you shouldn't get a command line at all.

Fedora Core 4 plans announced

Posted Jan 20, 2005 0:12 UTC (Thu) by ahz (guest, #27372) [Link] (3 responses)

What exactly FORTIFY_SOURCE? How does it compare to SSP (aka ProPolice) and Exec-Shield (already in Fedora Core 3)?

Linux distributions need strong stack protection enabled by default--starting first with network-enabled applications including daemons (e.g. Apache) and clients (e.g. Firefox).

Fedora Core 4 plans announced

Posted Jan 20, 2005 21:03 UTC (Thu) by vonbrand (subscriber, #4458) [Link] (2 responses)

Protection on executing data is already part of Fedora Core. Has been for quite some time now.

Fedora Core 4 plans announced

Posted Jan 21, 2005 23:09 UTC (Fri) by ahz (guest, #27372) [Link] (1 responses)

Yes, and Exec-Shield improved between FC releases, which implies ES had shortcomings.

I would like an expert's comparison on Exec-Sheild, SSP, and related technologies. Why does Fedora use Exec-Shield and OpenBSD use SSP?

If all security extensions cannot be integrated, it would be great to offer them otherwise. I would rebuild (recompile) my system, which is an Internet host, to get more security. Anyone willing to make a Hardened Fedora project that facilities this?

Fedora Core 4 plans announced

Posted Mar 1, 2005 8:41 UTC (Tue) by performanceman (guest, #28141) [Link]

It would be nice to see Fedora with great performance, right now is great but sometimes take time to do things, ie: yoper

http://www.yoper.com/forum2/index.php?showtopic=1010
P
erformance patches from Con Kolivas, i686 2.6.7 kernel, reiserfs
1.) All original sources, minimal patches.
2.) Compiled with i686 against latest gcc
3.) Stripping
4.) Prelinking
5.) Latest gcc and glibc and other sources
6.) Keep everything only dependent to what it really needs not what the ./configure happens to find.
7.) Hdparm on install