Slashdot Mirror

If you want to setup a cloud deployment on, say, Amazon's EC2, it's quite easy, and then once you're up and running you can then decide if you want to buy support for that deployment.

If instead you visit RedHat's cloud page, you'll see no similar guide to getting started. As far as I can tell, this is because you need to have a RHEL license to even get access to their EC2 AMI files. As close as you can get for free is the RightScale AMI for CentOS.

A lot of technical decision are made through the path of least resistance for getting started. Right now, if EC2 is your cloud platform, and you want to deploy a simple setup that you can add support to later, Ubuntu is where you'll end up at. A someone who leans toward RedHat for servers, I've been frustrated lately that I can't do free proof of concept deployments of RHEL on EC2, and then add support to them only once the result has been signed off as working. And for always unpaid setups, people don't really trust the RightScale AMI images the way they do the official Ubuntu ones either.

http://kbase.redhat.com/faq/docs/DOC-22461

There may be other problems too, my cursory examination of the kernel backtraces I got didn't necessarily indicate a deadlock, but I'm not overly familiar with linux backtraces either. My impression is that nfs over loopback is pretty rare - I think the automounter is smart enough to use bind mounts for local filesystems rather than nfs, which is pretty much the only commonly used form.

This is modded as funny, but if you see their Life Cycle page at:
https://www.redhat.com/security/updates/errata/

You can see that there's a 3 phase cycle for release support. Major versions are supported for 7 years, with the first 4 years being "primary support", i.e. new features, hardware support, and bug / security patches, and then after that they move into a maintenance cycle in which they will first not push new features, and finally only push bug fixes / security patches that are marked as "critical".

This is important to those of us that manage thousands of RHEL boxes.

Btw, got my RHCE a couple of months ago! So, technically, for me, the longer RHEL6 takes to come out, the better - my RHCE is valid until RHEL7.

https://www.redhat.com/apps/store/desktop/
https://www.redhat.com/apps/store/server/

They stopped?

https://www.redhat.com/apps/store/desktop/
https://www.redhat.com/apps/store/server/

They stopped?

ftp://ftp.redhat.com/pub/redhat/rhel/beta/6/

Or torrent it:
http://www.torrentreactor.net/torrents/5568298/RHEL-6-Beta-64-Bit
Don't forget to check the sha1sum, which can be verified on the first address:
e0a3a906d7bbbc57b411a213bd5d6ad44d851689 RHEL6.0-20100414.0-AP-x86_64-DVD1.iso

Due diligence, they call it.

But perhaps it's not too late for Oracle to try one of these numbers:

Contact Info

It does however support Itanium on Linux

Well kind of. Red Hat recently announced that they were dropping Itanium starting with Red Hat Enterprise Linux 6. How long will it be before the rest of the distro gang follow suit?

That poses another problem. In general, vendor support contracts for a given piece of software usually become inapplicable if you modified the code in question. At least, this is how RedHat operates (See: Modified RPMs) so it's reasonable to expect that other vendors have similar policies.

IMHO, this is a reasonable policy, because the complexity in supporting the software distribution increases quite a bit if you can't guarantee the code\behavior is vanilla. So while you're still free to integrate upstream fixes, most businesses won't, because then they lose their support.

Disclaimer: I am not attempting to justify Oracle/Sun's decisions. I believe everyone should have access to security patches.

Actually x86_64 Linux scales up to 255 CPUs at least:
http://www.redhat.com/rhel/compare/

And Redhat is using older kernels (with *some* new features backported), so more modern kernels might be even more.

We have a 48-core machine here used as a VM host.

When do you think Linus Torvalds will get sued?
He installed the Gstreamer ugly plugins
https://bugzilla.redhat.com/show_bug.cgi?id=439858#c19
and ugly includes MPEG-LA patents
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-ugly-plugins/html/
and users have patent liability:
http://weblogs.mozillazine.org/roc/archives/2010/01/h264_licensing.html

See the upgrade guide for upgrading 4.5 to 4.6... it's a 280 line upgrade guide:
http://www.openbsd.org/faq/upgrade46.html ...on RedHat and CentOS, to go from RHEL 5.3 to RHEL 5.4 I did "yum -y update". That's it.

You can just do the OpenBSD upgrade without reading those instructions... as you did with RHEL.

If you'd actually started to read those instructions, you'd have seen they outline basically all feature changes between the previous and current release. See:

scrub in all no-df max-mss 1440

can be replaced with a rule using the new "match" action:

        match in all scrub (no-df max-mss 1440)

Did the yum upgrade automatically make all necessary syntax changes in all corner cases in your config files to adapt them for the newest versions of the software? Obviously not... You're left to figure those out yourself. If the new version of iptables uses different options for some obscure option, you're screwed. Oh well, guess you should have read the RHEL 5.4 errata, which happens to be SEVERAL THOUSAND LINES http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.4/html/Release_Notes/index.html

No I am well aware of the role that corporate contributions have played - like IBM's help with Apache, etc.

Are you really well aware of the role that corporate contributions have played? It's much more than one large company helping out with one project. The Apache Software Foundation and Free Software Foundation have significant corporate sponsorship. 75% of Linux kernel code is written by paid developers. Continued Firefox development is made possible via search royalties. Red Hat is significantly involved in many of the projects that make modern Linux systems useful.

I seriously doubt open source software would be anywhere as near as useful as it is today without the extensive corporate sponsorship and contributions. I don't think it'd be very competitive outside of perhaps academia.

However to expect a corporation to fund a project indefinitely is ludicrous

I didn't say otherwise. I really don't care about accessible open-source software.

Something can be poor without there being a high quality alternative in existence (yet). Just because everyone in a class got an "F", doesn't mean it's a good grade (even though almost everyone else got the same, except one student got a C and another got an B.. the one who got the C gets to be president, the one who gets the B never gets told about their grade, while their employer patents the invention and sells it for billions as uber-expensive product for "Enterprises" only).

I am comparing as in having 4 computers, each with 1 CPU and their own OS image and 16gb of RAM, assigned 25 ip addresses, each serving web page requests (received from a load balancer); versus 1 computer with 4 cores and 64gb of RAM, assigned 100 ip addresses, say having a single Dell PowerEdge R510. versus Multi-proc setup clusters, HTPC, etc.

Compared to other Unices... Solaris, FreeBSD, z/OS, compared to running multiple OS instances on the same hardware, each in its own Xen VM.

It's surprising, but scaling out several Linux virtual machines on the same piece of metal, oddly, seems to get more than triple throughput (server-wide) for serving large static web pages, particularly with maximal numbers of simultaneous connections.

If you equally divide the physical server into 4 virtual machines, each would have only 15.3gb of memory to work with (after subtracting ~3gb overhead due to virtualization), intuitively one would expect less total http throughput from the server, but it's not what happens. Instead each instance gets pretty close to full performance..

Windows requires excessive tuning and IIS still a little bit slower.

Plenty of RAM and aggressive read caching, so there should no I/O bottleneck.

My only conclusion at this point (which might be wrong), is that it's a great advdantage to have 2 cores, but the third and fourth cores go underused, for some reason, my best guess is some sort of kernel-related lock contention or issue in the network stack that impacts web performance benchmarks with large number of clients.

Redhat's page on KVM performance seems to confirm this too: LAMP: For Apache webserver workloads, up to 139 percent of bare metal performance with great scalability.

I'm quite sure that Redhat's "support" model is designed to frustrate and confuse.

You pay per server per year. That's not exactly confusing. Frustrating only in the sense that... you have to pay for it.

Customer: "I'm a FOSS DEVELOPER! YOU'RE SELLING ME MY OWN CODE!"

http://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/os/SRPMS/
No they're not. They're selling you binary packages and the ability to call them up at 2:30 AM to get your issues fixed. If you want your code, it is right there for you to download without issue.

They can smugly tell me "see, software isn't free?" and feel much more comfortable signing cheques for $1500/year.

The software is free. If they don't understand what they're purchasing, that's their problem, and only yours if you decide to make it your problem.

Well, you obviously can't even read, so I'm not surprised that the engineers couldn't help you. http://www.redhat.com/support/policy/sla/contact/ The 'entire thing' has been outsourced to India? Huh.

Red Hat Enterprise Virtualization isn't even funny. It's $750/socket for 24x7 phone support, per year. Hyper-V is free. Xen is free. KVM is free. ESXi is free. If you don't want Hyper-V without support, buy Windows Server Standard, it's $350 a year for the same support, and it's per server. You don't get dinged by the processor. If you're going to pay through the nose, you better be getting VMWare because at least they have the crazy advanced feature-set to back it up.

But, Red Hat Advanced Platform (starting at $1499/year, with unlimited sockets/memory includes clustering, GFS (to support live VM migration) and unlimited supported Red Hat guests, which inherit the base features (clustering and GFS). You don't get the RHEV management platform, but the server supports being managed by the RHEV management platform (which is a separate "per managed socket subscription of $500).

I think you've misunderstood RH's virtualisation strategy, the RHEV product *is* the competitor to VMWare's "crazy advanced feature-set" (competing with their vCenter product set), but (AFAIK) there is no "cheap" VMWare solution that provides HA, whereas RHEL Advanced Platform (without RHEV) does.

On RHEL standard, you're limited to 4 supported free Red Hat VMs, and 2 sockets on the host, starting at $349/year.

Red Hat Enterprise Virtualization isn't even funny. It's $750/socket for 24x7 phone support, per year. Hyper-V is free. Xen is free. KVM is free. ESXi is free. If you don't want Hyper-V without support, buy Windows Server Standard, it's $350 a year for the same support, and it's per server. You don't get dinged by the processor. If you're going to pay through the nose, you better be getting VMWare because at least they have the crazy advanced feature-set to back it up.

But, Red Hat Advanced Platform (starting at $1499/year, with unlimited sockets/memory includes clustering, GFS (to support live VM migration) and unlimited supported Red Hat guests, which inherit the base features (clustering and GFS). You don't get the RHEV management platform, but the server supports being managed by the RHEV management platform (which is a separate "per managed socket subscription of $500).

I think you've misunderstood RH's virtualisation strategy, the RHEV product *is* the competitor to VMWare's "crazy advanced feature-set" (competing with their vCenter product set), but (AFAIK) there is no "cheap" VMWare solution that provides HA, whereas RHEL Advanced Platform (without RHEV) does.

On RHEL standard, you're limited to 4 supported free Red Hat VMs, and 2 sockets on the host, starting at $349/year.

So, how much does a support contract with unlimited incidents from Microsoft cost for Windows 2008 Slightly Less Artificially Crippled Edition (TM)? Keep in mind you need to buy the software too, and that starts around $1000 and does not come with any support whatsoever.

Redhat et al are doing xen .. I think (corrections please)

Correction: Red Hat aquired Qumranet, the inventors of KVM (link), so Red Hat is abandoning Xen in favor of KVM as well.

The actual link we used for the conference won't help you much without a login, this was a registration-required event. The agenda is here: http://www-2.virtualevents365.com/rhexp/agenda.php . The best public area is probably http://www.redhat.com/rhev/ .

PDF/PPT downloadables were provided during the all-day session and supposedly all the A/V content (the actual recordings / transcripts) will be available on the RedHat site for 3 months after they are posted... as with all interactive presentations there was a lot discussed that wasn't on the slideshow.

BTW, I've heard of some diehard Mircosofties getting windows tats. Wonder if Linux coders have a Tux tat. (yuck).

I have a co worker that got a fedora tattoo a little while back.to add to his Red Hat tattoo. A quick google search shows that some people get Tux tattoos.

[Does] anyone besides debian-experimental bother?

Fedora 12 includes Rakudo Perl 6.

For comparison, Fedora 13 will likely include Python 3.

Gentoo? I've found it to be rather good. Maybe you're not a ricer though and want to use something mainstream like redhat/centos? Have any of these people actually RTFM that they are saying is inadequate or lacking? What is the author's definition of "good" documentation? The docs I've found for linux have generally been superior to ones I've come across from Oracle, Novell, or Microsoft.

But when they spend more bandwidth on nettiquitte than actual content, its just not worth it.

Gentoo? I've found it to be rather good.
Maybe you're not a ricer though and want to use something mainstream like redhat/centos?
Have any of these people actually RTFM that they are saying is inadequate or lacking? What is the author's definition of "good" documentation? The docs I've found for linux have generally been superior to ones I've come across from Oracle, Novell, or Microsoft.

We Linux is not so easy, and believe it or not,

Perhaps these links will be of help to you then. You seem to not be up-to-date.

• Red Hat Network/Satellite
• Novell's Endpoint Management
• Canonical's Landscape

Red Hat and Novell have quite a bit to help manage your Linux (and Windows, in Novell's case) infrastructure; this is only a quick sampling. If you're truly interested in it, you'll need to contact their representatives and have a dog-n-pony show, like the Microsoft ones you've attended.

Something makes me think that MVP Electronics, Inc. and Red Hat, Inc. would like to have a chat with him about trademark infringement.

This is a good thing.

Really?
Consider the consequences of this happening ... again:

Last week we discovered that some Fedora servers were illegally accessed. The intrusion into the servers was quickly discovered, and the servers were taken offline.
...
One of the compromised Fedora servers was a system used for signing Fedora packages. However, based on our efforts, we have high confidence that the intruder was not able to capture the passphrase used to secure the Fedora package signing key.

Now imagine an admin had performed a dist-style upgrade from Fedora 11 to 12 (install the F12 "release" RPM, then "yum update"), without knowing about this default change to his systems' security, because it would never have occurred to him that Fedora/RH could make such an incredible policy decision. A few days later the Fedora/RH servers are hacked (again), but this time they're not so lucky. Meanwhile, user "blogs" on the admin's network is told (by PackageKit) there are important security updates available, so he decides (without any malice) to go ahead and apply the updates. Thanks to this new "security" policy, he is able to do so, but unknown to him, he's just rooted the system, thanks to the injection of a modified (and re-signed) malicious package on the hacked Fedora/RH server. This malicious package begins by deactivating SELinux (root privileges), then proceeds to delivering it's malware payload across the entire system, and (depending on what's visible to the host) the rest of the network (perhaps also by E-mail).

Now you might think this would have happened anyway, even if it had been the admin who'd performed the update, but there are a few important differences:

• The system(s) are supposed to be the admin's responsibility. This is a crucial point, even in a "home" network. Someone has to be delegated to take responsibility for the system(s), because otherwise the result is conflict and chaos. So if the admin screws up, then he only has himself to blame, and users who screw up, should not affect any other account, or the system at large
• The admin has the ability to perform full system backups prior to deploying updates, so if things go wrong, then he has the ability to put them right. Users with selectively elevated privileges do not, and this is a potentially fatal combination
• There needs to a clear separation of privileged from unprivileged access on a computer system, so that incident like the above don't happen. User "root" doesn't run X11, doesn't run a Web browser, doesn't play games, in fact doesn't do anything other than essential maintenance, and thus is not susceptible to certain attack vectors like social engineering. Unprivileged users are, but this doesn't matter because they are (or should be) unable to make any system-wide changes

Even on a single-user system, Fedora's new Windows-style (in)security policy is dangerous, counter-productive, and frankly insane.

This is definitely not a good thing.

To quote Richard Hughes, the developer responsible for the braindeadness in the first place, and repeatedly trying to brag his competency of being a dickhead in the bugzilla(https://bugzilla.redhat.com/show_bug.cgi?id=534047).:

Every time somebody writes "Linux is about choice" something inside of me dies. Just because something can be done, doesn’t mean it should be done.

Source: http://blogs.gnome.org/hughsie/2009/09/23/linux-is-about-choice/

It seems that he interpreted his own words as "Just because you can do something, doesn’t mean you should do it. But for me, I can fucking make whatever 'choice' and screw everybody else. Bwahahaha!"

And his recent rants:

And so, long story short, we decided to revert the change for F12.

Part of being an open source maintainer (and also my job at Red Hat) is to ignore trolls, but some of the messages I was getting yesterday were just personal attacks and abuse. That’s not cricket at all.

(Source: http://blogs.gnome.org/hughsie/2009/11/20/the-fedora-12-installing-saga/)

But he was the one who was being a troll first. Quotes from the bugzilla:

• "It's not insecure. We've had the mechanism checked. The default policy may not be to your taste, but this is the "desktop" spin, not the "server" spin. " (btw, the two "spins" don't actually exist. --ed)
• "There's nothing to discuss here."
• "You either trust the Fedora repos or you don't."
• "I don't particularly care how UNIX has always worked."
• "You missed the "in my opinion" line in your reply."
• "There are other, *easier*, ways of rooting the system. "

Now, I'm wondering how on earth did someone got a job for being a devtroll. Red Hat pays him to develop, but trolling the bugzilla? I don't remember anyone "attacking him personally" on the bugzilla. I wasn't following the mailing lists though.

And he now seemed hurt because the users actually bothered to donate their own time correcting his mistake.

Grow up.

Wrong, Seth is not supporting this madness, although if you just pick one of his comments at random without reading the surrounding discussion and getting the context, you could get the wrong idea.

https://www.redhat.com/archives/fedora-devel-list/2009-November/msg01086.html

Important note: the policy in question will be changed, likely with an update to be issued tomorrow. The new policy will be more restrictive than that in Fedora 11 (it will require root authentication for each package installation operation). Please see the official announcement and the more extensive fedora-devel-list post for more details. Thanks.

Important note: the policy in question will be changed, likely with an update to be issued tomorrow. The new policy will be more restrictive than that in Fedora 11 (it will require root authentication for each package installation operation). Please see the official announcement and the more extensive fedora-devel-list post for more details. Thanks.

according to Seth Vidal:

$ pklalockdown --lockdown org.freedesktop.packagekit.package-install

Ref: https://www.redhat.com/archives/fedora-devel-list/2009-November/msg01055.html

The issue suddenly became much less of a big deal to me. In the end, it comes down to whether you trust the quality of Fedora packages and the security of their signing key. Either you do, in which case this isn't a problem, or you don't, in which case you shouldn't be using Fedora.

Things get complicated when the project's server are physically compromised. I agree that the mechanism is neat and very useful but the developers jumped the gun when they altered the default configuration without notifying anyone. This change wasn't even mentioned in the release notes. That alone raises questions about the project's development process.

Fedora prided itself with default security policy since it had SELinux enabled by default. This change is exactly in the reverse direction.

In some ways, I think this is a good idea. If users are used to "if I want to install something then I need to enter my/root's password," then they will get desensitised to the necessity of checking that the package is from a trustworthy source.

With Fedora 12's approach, because users will only be prompted for a password for installing unsigned packages, it makes it automatically more notable.

In any case, I agree with you that this is a poorly-thought-out, poorly-documented, and hard-to-locally-revert change. And thus sucks, despite honourable intentions. "The road to hell...," etc.

My favoured approach:

• Installing signed package from repository: prompt for user's password.
• Installing unsigned package/package from source other than repository: prompt for root's password.
• Upgrading signed packages from repository: no prompt.

The issue suddenly became much less of a big deal to me. In the end, it comes down to whether you trust the quality of Fedora packages and the security of their signing key. Either you do, in which case this isn't a problem, or you don't, in which case you shouldn't be using Fedora.

Things get complicated when the project's server are physically compromised. I agree that the mechanism is neat and very useful but the developers jumped the gun when they altered the default configuration without notifying anyone. This change wasn't even mentioned in the release notes. That alone raises questions about the project's development process.

Fedora prided itself with default security policy since it had SELinux enabled by default. This change is exactly in the reverse direction.

Cf another gem of a comment on Bugzilla: I don't particularly care how UNIX has always worked. Sigh.

God. Reading that thread made further reinforced my commitment never to install Fedora. I would dearly like to see the "use-cases" that Richard Hughes fella has dreamed up to rationalize this change.

They're in for a long battle.

Considering that the fix to this is already written out in one line of code in the same thread on the same day here:
https://www.redhat.com/archives/fedora-devel-list/2009-November/msg01055.html

And they have already admitted that the default security setting is not consistent with the philosophy they had built the Linux system on in the past. That's a pretty good turn around time for a mistake in the security area of an OS.

Interesting and wrong, I should say:

There's nothing to discuss here. Your problem is that pretending asking for root authentication for *local* users in *active* sessions... when installing *trusted* software adds security is... well.. only a sign of dogma, snakeoil and ignorance when it comes to providing a secure system.

There's a superficial kind of sense in what he's saying. After all, if someone has console access, he could already pwn the machine, right? Well, the keyword here is defense-in-depth. There are lots of reasons non-root, non-trusted users might want to run from the console. Linux on random net-cafe machines is one example, where all kinds of people use the console. A family PC running Linux (hey, not as farfetched as it sounds) might have different user accounts for each family member.

Sure, it's trivial to fix this with pklocalauthority, but should users have to? It's about as lame as telling folk, "hey, you can just switch off IIS if you don't need it."

It's sad that while Microsoft and Windows has made so many strides towards providing a secure-by-default configuration, Red Hat seems to be losing the plot. Cf another gem of a comment on Bugzilla: I don't particularly care how UNIX has always worked. Sigh.

Interesting and wrong, I should say:

There's nothing to discuss here. Your problem is that pretending asking for root authentication for *local* users in *active* sessions... when installing *trusted* software adds security is... well.. only a sign of dogma, snakeoil and ignorance when it comes to providing a secure system.

There's a superficial kind of sense in what he's saying. After all, if someone has console access, he could already pwn the machine, right? Well, the keyword here is defense-in-depth. There are lots of reasons non-root, non-trusted users might want to run from the console. Linux on random net-cafe machines is one example, where all kinds of people use the console. A family PC running Linux (hey, not as farfetched as it sounds) might have different user accounts for each family member.

Sure, it's trivial to fix this with pklocalauthority, but should users have to? It's about as lame as telling folk, "hey, you can just switch off IIS if you don't need it."

It's sad that while Microsoft and Windows has made so many strides towards providing a secure-by-default configuration, Red Hat seems to be losing the plot. Cf another gem of a comment on Bugzilla: I don't particularly care how UNIX has always worked. Sigh.

Read the response. It's actually a Red Hat employee making the complaint, calling it a security vulnerability. I wouldn't call a Red Hat employee complaining about this policy to a Fedora mailing list an attempt to coax RHEL usage.

Or you could install RHEL

That is what they want, apparently:
https://www.redhat.com/archives/fedora-devel-list/2009-November/msg00945.html

"Should the defaults be targeted towards home users or corporate desktop
considering the short lifecycle of Fedora and the target audience? I am
not sure there are corporate deployments but wouldn't they be heavily
customized their desktop deployments and kickstarting it anyway?"

thanks for the info. Well, that sucks :/ you _should_ be able to complete an install - even a graphical one - using only the keyboard (usual tab / space / enter stuff), though I'm not sure if you want to :). The bug I was thinking of is https://bugzilla.redhat.com/show_bug.cgi?id=524808 , you could try the kernel parameter 'intel_iommu=off' or 'iommu=soft' . But I really doubt it's that issue if you're on final, it seemed pretty certain that it was fixed.

We have to be careful with Apples-to-apples, here. RH sells a "subscription" to 24x7 unlimited support for $2500 per year—you can buy their box of software for $50. For Apple server, you get unlimited 24x7 support for $20,000 per year. (If that's too pricey, you can get 12-hour 10-incident support for $6000.)

That $6500 price for RedHat you found is volume pricing for a three-year unlimited support subscription, which would cost $7500 if you purchased it on a year-by-year basis for three years. If you purchased Apple's unlimited 24x7 support subscription for three years, it would cost $60,000.

I'm not saying it's wrong for Apple to play in the high-price arena; I'm just saying they prefer to. The last thing they need is to be undercut by some cheap-ass cloners who have found a market. I think Jobs made this clear this when he came back to Apple.

Cites:

https://www.redhat.com/apps/store/server/rhelap.html

http://www.apple.com/support/products/macosxserver_sw_supt.html

http://www.buy.com/prod/hp-red-hat-enterprise-linux-advanced-platform-with-3-years-24x7/q/loc/105/205856949.html

Of course, if you run a maintained version of any Enterprise Linux I'd put good bets down that they'll be patched shortly. If you spun your own distro, then you made the choice to maintain it yourself anyway.

The RHEL patch was released yesterday: https://rhn.redhat.com/errata/RHSA-2009-1548.html

Naah, CVE 2009-3547 traces on the RH Bugzilla as Bug 530490, "kernel: fs: pipe.c null pointer dereference". Nothing in there about mmapping to page 0. (Pipe filesystem pointer dereferences?)

OTOH, CVE 2009-2695 also googles to a RH bugzilla page, Bug 517830, " kernel: SELinux and mmap_min_addr". The description on that page sounds suspiciously like the subject of current discussion. This page also has RH patches, in this case in two different RH Security Advisory links.

There appear to be another bugzilla pages about this issue: Bug 532938, which is a member of the RH security team saying that vm.mmap_min_addr should default safe (nonzero), turning on page 0 protection by default.

Naah, CVE 2009-3547 traces on the RH Bugzilla as Bug 530490, "kernel: fs: pipe.c null pointer dereference". Nothing in there about mmapping to page 0. (Pipe filesystem pointer dereferences?)

OTOH, CVE 2009-2695 also googles to a RH bugzilla page, Bug 517830, " kernel: SELinux and mmap_min_addr". The description on that page sounds suspiciously like the subject of current discussion. This page also has RH patches, in this case in two different RH Security Advisory links.

There appear to be another bugzilla pages about this issue: Bug 532938, which is a member of the RH security team saying that vm.mmap_min_addr should default safe (nonzero), turning on page 0 protection by default.

Naah, CVE 2009-3547 traces on the RH Bugzilla as Bug 530490, "kernel: fs: pipe.c null pointer dereference". Nothing in there about mmapping to page 0. (Pipe filesystem pointer dereferences?)

OTOH, CVE 2009-2695 also googles to a RH bugzilla page, Bug 517830, " kernel: SELinux and mmap_min_addr". The description on that page sounds suspiciously like the subject of current discussion. This page also has RH patches, in this case in two different RH Security Advisory links.

There appear to be another bugzilla pages about this issue: Bug 532938, which is a member of the RH security team saying that vm.mmap_min_addr should default safe (nonzero), turning on page 0 protection by default.

"I installed the 64-bit version on two AMD machines (one laptop and one desktop) and both of them have issues with random lockups after 10 minutes or so."

May well be https://bugzilla.redhat.com/show_bug.cgi?id=517625 , if they also have AMD graphics adapters. Try booting with pcie_aspm=off as a kernel parameter. If that helps, add a comment on the bug report to note that you have the same problem, with output of 'lspci -nn'.

"How many times have you been able to do a 'yum update' or 'preupgrade' without having to worry about whether the system will be able to boot correctly?"

Around 99.9% of the time.

"How many times has anaconda crashed mid-install"

Aside from a known bug [1] (a well documented common bug), zero (or at least as far as I remember). And I've been using Fedora since F2 on machines ranging from PII/366 laptop to 24 core monsters.

"...or failed to detect your RAID and decided instead to wipe individual drives without really telling you, or any number of other nagging problems?"

0.
Granted, I may not be as "successful" as you are- as I only manage ~20 different Fedora machines (as a side job) - but who am I to argue with your well documented arguments... (You forgot about RPM-hell. If you're taking the time to spread FUD, at least do it right!)

- Gilboa
[1] https://bugzilla.redhat.com/show_bug.cgi?id=501057

- There are two separate clipboards, a mouse one and a keyboard one. Middle-click will often paste something different to ctrl-v. In this day and age, I'm sorry, I can't be generous - this is fucking retarded. Fix it, Canonical.

That's a feature of X that's been around for about ever, people would rise up and raise hell if they did that. I'm sorry you can't deal with that.

- Sometimes selection copies stuff, sometimes it doesn't. Be consistent. I'd say make it never copy stuff.

See above, this is the same problem you're having with the middle click. Here's how it works, highlighting text puts it in the middle click copy buffer, that's it. There's a keyboard buffer, and a mouse buffer, and never do the two meet.

- This bug meant that I had to hack an init.d script by adding 'sleep 5', just to get a DHCP server working on the Ubuntu box because of the way dhcp3-server assumes interfaces will be immediately available and NetworkManager makes them available asynchronously. Ubuntu enthusiasts tell me NetworkManager is pretty much only good for wireless, and disable it for wired connections. Utterly pathetic. We desperately need Canonical to get this done - and competently.

If you can't set the wired connection up by hand you've got bigger issues to deal with. It's unix, right tool, right job.

- Make up your mind as to what one should use to install packages. There's an add/remove software GUI, but there's also Synaptic Package Manager. Make up your mind, Canonical!!!!!

Again, right tool, right job. If you're a mouth breather that doesn't understand packages stick to the kiddie pool (add/remove), if you understand that some programs are split in to multiple packages and understand that libraries exist, then use synaptic. If you need a quick and dirty install of a single package (and dependencies) use apt-get. Right tool, right job, it can't be repeated enough.

- Better firewall configuration. I know I've been told a million times that you can't make a GUI for iptables because it's too complex, but I beg to differ - at least you can make a GUI for it that implements a decent swathe of its functionality. No, ufw doesn't cut it, it sucks. Not enough functionality.

Firestarter

And how about a firewall that scans app binaries, and gives access on a per-binary basis?

That functionality just doesn't exist. IPTables doesn't know jack about which binary opened a socket, just the ports and IPs involved. SELinux/AppArmor might be a good place to start looking for that level of control, but frankly I don't know enough about either to say definitively.