Note that despite my public comments about it beign a bad idea to ship extremely untested compilers in a major release, I actually think that it would be wonderful to have people who are ready to face the consequences to try the new 2.96.

It's not been all that widely tested, but if you kno a bit about what you're doing (or want to learn), gcc-2.96 _does_ potentially create better code, and if nobody is willing to test it, any potential bugs (be they in the kernel sources and triggered by a smarter compiler, or in the compiler itself) won't be found.

So please do try it out, but please mention the fact if you end up having to report a bug (it won't make your bug-report be ignored, don't ever worry about something like that. But i would be good to have an older compiler handy to correlate the bug with the compiler for sure).

In fact, I'd love to hear about experiences even with the CVS snapshots. I just don't like them showing up in distributions ;)

Now, now, I'd love to se reports of expecially the new updated compiler. I've not actually seen a single report of problems for the kernel even with the old 2.96, it's just that I've seen too many user-space problems that I would be hesitant to use it for the kernel.

Despite my dislike of releasing snaopshot compilers, I'd _much_ rather see Red Hat just dropping their "kgcc" thing, and in order to do that people do ned to test with the new compiler.

I just want people to mention the fact, so that I can correlate any bug-reports with a compiler version. Just in case. It can be important (and not just because of compiler bugs, but due to real kernel bugs that just were hidden by pure luck with other compilers). And it helps a LOT if you have another compiler available to compare with.

I wonder how their approach compares to the RSBAC stuff, though. The RSBAC (by Amon Ott) has all the infrastructure available to have policy based access control; whenever an access decision has to be taken, a call via some interface is made to a module, which then takes the decision ... Just like PAM in userspace. http://www.rsbac.org/

I think it's a good approach and I think, it has gone much further than the NSA stuff. I'd prefer to have RSBAC merged in 2.5.

The Security-Enhanced Linux has a well-defined architecture (named Flask) for flexible mandatory access controls that has been experimentally validated through several prototype systems (DTMach, DTOS, and Flask). The architecture provides clean separation of policy from enforcement, well-defined policy decision interfaces, flexibility in labeling and access decisions, support for policy changes, and fine-grained controls over the kernel abstractions. Detailed studies have been performed of the ability of the architecture to support a wide variety of security policies and are available on the DTOS and Flask web pages accessible via the Background page (http://www.nsa.gov/selinux/background.html). A published paper about the Flask architecture is also available on the Background page. The architecture and its implementation in Linux are described in detail in the documentation (http://www.nsa.gov/selinux/docs.html).

RSBAC appears to have similar goals to the Security-Enhanced Linux. Like the Security-Enhanced Linux, it separates policy from enforcement and supports a variety of security policies. RSBAC uses a different architecture (the Generalized Framework for Access Control or GFAC) than the Security-Enhanced Linux, although the Flask paper notes that at the highest level of abstraction, the the Flask architecture is consistent with the GFAC. However, the GFAC does not seem to fully address the issue of policy changes and revocation, as discussed in the Flask paper. RSBAC also differs in the specifics of its policy interfaces and its controls, but a careful evaluation of the significance of these differences has not been performed.

some PC BIOS chips are now coming with a default Microsoft setting, which makes them hostile to some functionalities of other OS. If particular under Linux, a PCI Winmodem did NOT function with the Win98 BIOS setting, but did fine with BIOS choice "Other OS". Possible, other PCI devices under Linux OS might be simmilarly afflicated.

This indicates a need for Linux install software to be equipped with a utility to probe the BIOS and report back "Linux hostile" BIOS settings. Today most Newbies are getting new PC boxes equipped with WinModems. Hostile BIOS settings will block their capability to get on-line.

And if his wrists hurt, he's definitely doing the right thing by laying off.

<soapbox>

I _know_:

8 months in a neck brace due to cervical spine damage (don't hunch forward while reading cool/clever code). 1.5 years physical therapy for that damage (permanent, _do not_ hunch forward while reading cool/clever code). 7 months paralysis of left arm (don't put weight on your elbow on hard surface while reading cool/clever code) 5 months paralysis of lower left leg (don't cross your legs while leaning on left elbow while...).

The nerve damage can be helped a bit with massive doses of vitamine B if you're lucky, but they don't fully recover in my experience. Bones don't recover at all.. ever.

Remember the thousand times your mom said sit up straight?.. I sure do ;-)

</soapbox>

I'm one of the folks that works on the PowerPC portion of the kernel. I've noticed for some time that what's available at kernel.org and what's being worked on by those of us who maintain our little portion of the PowerPC tree is more and more out of sync.

How it's got there etc etc etc at this stage isn't important. First how to fix it and how to make sure it doesn't happen again does concern me.

Currently the diff between test13-preX and the master fsmlabs.com ppc tree is about 450k. Is the right thing to start with that patch get that into the test13-preX series?

I would REALLY appreciate it if this could be made to happen. I've got a whole boatload of RS/6000 (aka pSeries) hardware that will be starting to work once this patch is in. It's truely a shame to have to explain to people that kernel.org *SHOULD* be the place to get a good kernel but given that things are out of sync to have to point them somewhere else.