Slashdot Mirror

Yup, that's Ubuntu before the suckage added.

  Or Unbuntu with the suck massaged out: http://www.linuxmint.com/

    Too light to contain suck: http://www.archlinux.org/

    Too tiny to hold suck: http://puppylinux.com/

    Got their suck fixed a few releases ago, it's all good now: http://www.fedoraproject.org/

    fixed their suck a while ago too, lookin' good: http://www.freebsd.org/
 
    supports all kinds of desktops that don't suck: http://www.mandriva.com/

    roll your own without the suck: http://www.gentoo.org/

Briefly: yes.

It's actually a bit more complicated than it sounds, though: http://directory.fedoraproject.org/

Using Kaffeine on Fedora, I tried playing a DVD by clicking on the "Play DVD" icon. The screen flashed different colors but the DVD did not play. It also gave no error or warning. At first I cleaned the DVD thinking it may have been scratched. I tried several different DVDs and got the same result. I even looked up the Kaffeine player on the fedora site. Nowhere does it mention on the site what could be wrong. Out of curiosity, "cat /var/log/messages | grep DVD". There I got messages about to the effect of "DVD Encrypted" and something about "decrypting libraries not found". That's when I looked on the internet and figured out that libdvdcss was not installed and why. It only took like ten minutes to fix but it would drive a novice user away from Linux.

Fedora does it too http://fedoraproject.org/wiki/Statistics

Not sure about other distros

Fedora has similar statistics at at fedoraproject.org/wiki/Statistics.

You can always grab fedora.

Or you can grab debian (which ubuntu is based on), with almost 30,000 packages, and without the fugly Ubuntu wallpapers.

Restoring backups takes a while regardless, but sharing printers? Configuring (the vast vast vast majority of) drivers? REINSTALLING THE OPERATING SYSTEM?!

Man, you need to start running Linux. Ubuntu is one distro that prides itself on user-friendliness. Fedora is another, that tries more to stay on the cutting edge of software releases. Download a live CD of either - you can boot from the CD and try using it without even installing for a while. Once you've gotten accustomed to it, go ahead and blow Windows off your hard drive (after backing up your important stuff, of course.) It'll be the best thing you ever did.

You should be aware that Debian is not allowed to use the trademark "Firefox" and also have the ability to apply patches such as security fixes(1). It's not called "Iceweasel" out of anything but necessity. You think this is a Debian-specific issue? Well, no, it's actually a major problem for all other distributors as well(2).

1
2

So the links are 5 years old, but the issues surrounding the trademarks haven't changed or gone away. Distributions shipping "Firefox" have abrogated their ability (and responsibility) to be able to apply changes and security updates to the software without the explicit concent of Mozilla Corporation.

Not exactly free software when it comes on those terms, is it?

Regarding the kernel, I assume you're referring to the non-free firmware removal. Maybe you haven't been fully informed that the non-free firmware was actually removed from the upstream kernel sources as well. As a result, the Debian kernels are far from "non-standard", they are standard!

Regards,
Roger

[FFS Slashdot, it's 2011 and you still can't handle UTF-8!]

I thought it was already done partially, and actually is :))

http://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming

What is the benefit? In using same configuration when moving OS from one server to another?

Yeah, actually that is ugly thing - I am tired of rewriting MAC addresses, but maybe I want it so! :)

[root@Fedora ~]# cat /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x8086:0x108c (e1000e) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:30:48:01:ab:cd", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x8086:0x109a (e1000e) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:30:48:02:ab:cd", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

Actually, Matt Domsch is from Dell ... not Redhat. So you can take the tinfoil-hat-of-conspiracy off (or put on another layer depending on your feelings towards Dell). This change is coming from an actual *need* from a certain segment of Linux users/admins. I suspect anyone who has had to deal with NIC failure/reconfiguration on a system with more than 2 cards will welcome this as it is trying to take advantage of newer BIOS technology to deterministically assign names to cards based on the actual physical location. Those with 2 or less will have to do little to no work in order to adapt to a change in nomenclature.

This change won't affect desktop people at all. The vast majority only have one NIC and they don't even know/care what it is called since Network Manager takes care of everything. Also, there are bug days being scheduled tomorrow to make sure that all the wrongly hard-coded scripts and programs are flushed out and fixed so hopefully we have a more manageable system going forward. If you care, participate in the bug days so that this change can be seamless:

https://fedoraproject.org/wiki/Test_Day:2011-01-27_Network_Device_Naming_With_Biosdevname

http://lists.fedoraproject.org/pipermail/devel-announce/2011-January/000746.html

Summary: Fedora infrastructure intrusion but no impact on product integrity

On January 22, 2011 a Fedora contributor received an email from the Fedora Accounts System indicating that his account details had been changed. He contacted the Fedora Infrastructure Team indicating that he had received the email, but had not made changes to his FAS account. The Infrastructure Team immediately began investigating, and confirmed that the account had indeed been compromised.

At this time, the Infrastructure Team has evidence that indicates the account credentials were compromised externally, and that the Fedora Infrastructure was not subject to any code vulnerability or exploit.

The account in question was not a member of any sysadmin or Release Engineering groups. The following is a complete list of privileges on the account:

• SSH to fedorapeople.org (user permissions are very limited on this machine).
• Push access to packages in the Fedora SCM.
• Ability to perform builds and make updates to Fedora packages.

The Infrastructure Team took the following actions after being notified of the issue:

• 1. Lock down access to the compromised account
• 2. Take filesystem snapshots of all systems the account had access to (pkgs.fedoraproject.org, fedorapeople.org)
• 3. Audit SSH, FAS, Git, and Koji logs from the time of compromise to the present. Here, we found that the attacker did:
• • Change the account's SSH key in FAS
  • Login to fedorapeople.org

  The attacker did not:

  • Push any changes to the Fedora SCM or access pkgs.fedoraproject.org in any way
  • Generate a koji cert or perform any builds
  • Push any package updates

Based on the results of our investigation so far, we do not believe that any Fedora packages or other Fedora contributor accounts were affected by this compromise.

While the user in question had the ability to commit to Fedora SCM, the Infrastructure Team does not believe that the compromised account was used to do this, or cause any builds or updates in the Fedora build system. The Infrastructure Team believes that Fedora users are in no way threatened by this security breach and we have found no evidence that the compromise extended beyond this single account.

As always, Fedora packagers are recommended to regularly review commits to their packages and report any suspicious activity that they notice.

Fedora contributors are strongly encouraged to choose a strong FAS password. Contributors should *NOT* use their FAS password on any other websites or user accounts. If you receive an email from FAS notifying you of changes to your account that you did not make, please contact the Fedora Infrastructure team immediately via admin@fedoraproject.org.

We are still performing a more in-depth investigation and security audit and we will post again if there are any material changes to our understanding.

--

Jared Smith

Fedora Project Leader

Your point is? The rpmforge website is apparently cited on the fedora project website, as it is listed here. What else do you want?

homebrew enabling your Wii lead to mostly homebrew being used, as opposed to the homebrew enabling exploits being used mostly for piracy (there was of course some piracy, but most had Homebrew Channel and a handful of games/emulators before tracking down pirated channels)

According to someone I spoke with on fedora-legal, the vast majority of ROMs run in an NES emulator are pirated.

As mentioned, the 2.6.37 kernel is in Fedora rawhide now, and it works fine with the current (Fedora 14) release if you want (or need) to run it:

http://koji.fedoraproject.org/koji/buildinfo?buildID=212634

The official Nvidia driver installer compiles and runs cleanly against it, making early use easier.

wow! intel is really keeping up with whats What hot and new , intel open source Now sounds like intel really wants to please OSS users like on Arrandale when they pull these kinds of stunts, TFA:

Intel decided not to send out any Sandy Bridge CPU samples to us, so we are unable to deliver test results, but all I got were frustrated journalists asking me how to get the Sandy Bridge graphics working under Linux.

Arrandale is also a complete mess on some platforms like fedora for e.g.Currently now running gentoo with xorg 1.9. and kernel 2.6.37.7 and feeling lucky that most things are now working on an Arrandale platform.

If you look at the average Google user, they're not technical enough to deal with it, and Google doesn't want to lose a single eyeball.

On the flip-side you can just turn it on and deal with it. The Fedora Project has enabled IPv6 and just post the Known Problems and tell users to how fix it for themselves.

We'll never get there if we never deal with turning it on. Google has done it the safe and cautious way. Fedora has done it the deploy and fix after way. The point is to just start getting it turned on.

If you look at the average Google user, they're not technical enough to deal with it, and Google doesn't want to lose a single eyeball.

On the flip-side you can just turn it on and deal with it. The Fedora Project has enabled IPv6 and just post the Known Problems and tell users to how fix it for themselves.

We'll never get there if we never deal with turning it on. Google has done it the safe and cautious way. Fedora has done it the deploy and fix after way. The point is to just start getting it turned on.

Here's one of the better criticisms of dropping SUID, and it's from an Openwall developer. These criticisms are echoed by almost everyone thinking about removing SUID.

There's a lot of talk lately regarding replacing the SUID bit on program
binaries in Linux distros with filesystem capabilities. Specifically,
Fedora and Ubuntu are heading in that direction.

Fedora:
http://fedoraproject.org/wiki/Features/RemoveSETUID
https://bugzilla.redhat.com/show_bug.cgi?id=646440

Ubuntu:
http://www.outflux.net/blog/archives/2010/02/09/easy-example-of-fscaps/
https://wiki.ubuntu.com/Security/FilesystemCapabilties

While in general this is a good idea, there are issues with it, in
arbitrary order:

- Some currently-SUID programs are aware of them being (potentially)
SUID, and will drop the "more privileged" euid when it is no longer
needed, but they will probably not be aware of them possessing
capabilities. This may result in larger parts of the programs
(sometimes orders of magnitude larger) running with elevated privileges
(or with allowed-to-be-elevated privileges, which is a privilege on its
own and is usable through vulnerabilities that allow for arbitrary code
execution). Let's consider ping, which appears to be the classical
example of "where filesystem capabilities will help" (or so it is
claimed). IIRC, it starts by acquiring a raw socket (NB: of a certain
somewhat-limited type), then drops root privs (if it was installed SUID
root and run by non-root), then proceeds to parse the command-line,
resolve the provided hostname, and so on. If the SUID bit is replaced
with cap_net_raw+ep, as seen in Kees' example above, will ping know to
drop this capability? Hardly. Not without a source code patch.
Besides, dropping the capability might [need to] require privileges
beyond CAP_NET_RAW itself (recall the capability-dropping attack on
sendmail from a decade ago). So does moving from SUID root to
cap_net_raw+ep improve security? Most likely not. On the contrary, it
results in hundreds of lines of ping's code and thousands of lines of
library code (DNS resolver) running with elevated privileges, as
compared to just a few lines of ping.c, which was the case with simple
SUID root. Granted, those "elevated privileges" are a lot less than
root privileges, but they're a lot more than having a single raw socket
of a specific type.

- In some cases, the capability sets being granted are (almost)
equivalent (or expandable to) full root powers. This is seen in:

http://people.fedoraproject.org/~dwalsh/policycoreutils_setuid.patch

-%attr(4755,root,root) %{_bindir}/newrole
+%attr(0755,root,root) %caps(cap_audit_write,cap_setuid) %{_bindir}/newrole

-%{_sbindir}/seunshare
+%attr(0755,root,root) %caps(cap_setuid,cap_dac_override,cap_sys_admin,cap_sys_nice) %{_sbindir}/seunshare

This mostly just sweeps the SUID root under the rug, where the sysadmin
will hopefully not see it and thus feel safer. However, it may expose
more problems in the programs if they knew to drop root, but wouldn't
know to drop the capabilities (same issue I described above for ping).

Granted, vulnerabilities of certain classes might become unexploitable
or be partially mitigated. For example, if no direct code execution is
possible (not a buffer overflow, etc.), but "only" privileged access to
an attacker-provided arbitrary pathname is possible, then "newrole"
above would be protected, but "seunshare" above would not (because of
cap_dac_override).

- Completely getting rid of SUID root pro

Here's one of the better criticisms of dropping SUID, and it's from an Openwall developer. These criticisms are echoed by almost everyone thinking about removing SUID.

There's a lot of talk lately regarding replacing the SUID bit on program
binaries in Linux distros with filesystem capabilities. Specifically,
Fedora and Ubuntu are heading in that direction.

Fedora:
http://fedoraproject.org/wiki/Features/RemoveSETUID
https://bugzilla.redhat.com/show_bug.cgi?id=646440

Ubuntu:
http://www.outflux.net/blog/archives/2010/02/09/easy-example-of-fscaps/
https://wiki.ubuntu.com/Security/FilesystemCapabilties

While in general this is a good idea, there are issues with it, in
arbitrary order:

- Some currently-SUID programs are aware of them being (potentially)
SUID, and will drop the "more privileged" euid when it is no longer
needed, but they will probably not be aware of them possessing
capabilities. This may result in larger parts of the programs
(sometimes orders of magnitude larger) running with elevated privileges
(or with allowed-to-be-elevated privileges, which is a privilege on its
own and is usable through vulnerabilities that allow for arbitrary code
execution). Let's consider ping, which appears to be the classical
example of "where filesystem capabilities will help" (or so it is
claimed). IIRC, it starts by acquiring a raw socket (NB: of a certain
somewhat-limited type), then drops root privs (if it was installed SUID
root and run by non-root), then proceeds to parse the command-line,
resolve the provided hostname, and so on. If the SUID bit is replaced
with cap_net_raw+ep, as seen in Kees' example above, will ping know to
drop this capability? Hardly. Not without a source code patch.
Besides, dropping the capability might [need to] require privileges
beyond CAP_NET_RAW itself (recall the capability-dropping attack on
sendmail from a decade ago). So does moving from SUID root to
cap_net_raw+ep improve security? Most likely not. On the contrary, it
results in hundreds of lines of ping's code and thousands of lines of
library code (DNS resolver) running with elevated privileges, as
compared to just a few lines of ping.c, which was the case with simple
SUID root. Granted, those "elevated privileges" are a lot less than
root privileges, but they're a lot more than having a single raw socket
of a specific type.

- In some cases, the capability sets being granted are (almost)
equivalent (or expandable to) full root powers. This is seen in:

http://people.fedoraproject.org/~dwalsh/policycoreutils_setuid.patch

-%attr(4755,root,root) %{_bindir}/newrole
+%attr(0755,root,root) %caps(cap_audit_write,cap_setuid) %{_bindir}/newrole

-%{_sbindir}/seunshare
+%attr(0755,root,root) %caps(cap_setuid,cap_dac_override,cap_sys_admin,cap_sys_nice) %{_sbindir}/seunshare

This mostly just sweeps the SUID root under the rug, where the sysadmin
will hopefully not see it and thus feel safer. However, it may expose
more problems in the programs if they knew to drop root, but wouldn't
know to drop the capabilities (same issue I described above for ping).

Granted, vulnerabilities of certain classes might become unexploitable
or be partially mitigated. For example, if no direct code execution is
possible (not a buffer overflow, etc.), but "only" privileged access to
an attacker-provided arbitrary pathname is possible, then "newrole"
above would be protected, but "seunshare" above would not (because of
cap_dac_override).

- Completely getting rid of SUID root pro

See Fedora's page for the same feature.

In short, there is a system now which gives programs certain capabilities based on tags set in the file system. With this, running as root is not needed for most things.

Fedora's historical view, much like Linus's, has been that binary blobs are okay as long as they're running on special-purpose hardware, rather than the general-purpose CPU. Drivers, even though they *control* special-purpose hardware, run on the CPU, with complete access to the resources of the entire system, so the drivers themselves need to be open source to be part of Fedora proper, even if some of their functionality is implemented in a binary firmware blob.

This view is not shared universally in the Fedora community, and many (including a lot of Red Hat employees) are growing increasingly fed up with it. I would not be shocked to see Fedora do something like this in the not so distant future. Take a look at this, for example:

https://admin.fedoraproject.org/updates/F14/FEDORA-2010-18594

http://pki.fedoraproject.org/wiki/PKI_Main_Page

I started my career in I.T. with Novell, but I left it behind when I saw the writing on the wall. I had been wishing for a miracle for the company like Google acquiring it, since IMHO a easy intuitive GUI driven directory service is lacking in the Non-Microsoft world. Especially one that plays well with other operating systems. Yes you can use other operating systems in an AD environment, but not as "out of the box" as Novell IMHO. Oh well... I guess we will see.

Have you taken a look at Fedora Directory Server? Red Hat also sells/supports an enterprise version.

http://directory.fedoraproject.org/wiki/Screenshots

It was poor code quality. It took 2 years to get the bugs to a bearable level. Not that it's bug free now, see Pulseaudio bugs in Fedora.

And Lennart Poettering is following the exact same pattern on the Fedora mailing lists as always.

They can buy a license for it and distribute it as an add-on.

End users wouldn't be able to redistribute the AVC add-on to one another.

Linux is just an apt-get (or similar) away from it

On Ubuntu, trying to install any package containing an AVC decoder using apt-get front-ends such as Synaptic or Ubuntu Software Center puts up a big scary warning about patents. Clicking OK is an infringement in those jurisdictions where AVC patents controlled by MPEG-LA are valid.

H.264 is freely available for older versions of Windows.

Apart from the AVC decoder embedded in Flash Player, which AVC decoder for Windows XP, Windows Vista Home Basic, Windows Vista Business, or Windows 7 Starter is freely available from a U.S. source?

Fourth, they can support it as an add-on one must get from a third party, similar to how DVD playing worked in XP.

Mozilla doesn't consider it "making the web better" to encourage web developers to make pages that show I'm sorry, you need Frobozz Viewer 3.0 to view this file. It's only $19.99, please have your credit card ready.

In my not so humble opinion 389 is by far the best LDAP server. http://directory.fedoraproject.org/

389 is based on the old Netscape directory server (AKA NDS/IPlanet) code.

If you install EPEL you'll get an additional 4600+ packages.

However RHEL/CentOS are server operating systems, so a lot of packages that make sense on desktops are omitted.

The "shapes" derive from the Fedora Infinity logo, which iirc debuted with Fedora 8. It's basically the mathematical sign for infinity, rotated counter-clockwise by 45 degrees with the lowercase Fedora "f" imposed onto it. It's quite elegant.

Graphics-heavy Fedora Wiki page on F8 artwork.

"Ubuntu is more aimed at polished experience for the end user in terms of QA prior to the release. Fedora developers however rely on early user reports after the release."

This is not true.

https://fedoraproject.org/wiki/QA:Desktop_validation_testing
https://fedoraproject.org/wiki/QA:Installation_validation_testing

"Ubuntu is more aimed at polished experience for the end user in terms of QA prior to the release. Fedora developers however rely on early user reports after the release."

This is not true.

https://fedoraproject.org/wiki/QA:Desktop_validation_testing
https://fedoraproject.org/wiki/QA:Installation_validation_testing

SJVN: Look at the bug reports I linked to: they have confirmations from multiple reporters that the bugs are fixed. I've got two F14 systems and a couple of VMs here, I can run Brasero on any of them and it works fine, for instance. The only bug that you mentioned that isn't fixed, exactly, is the USB 3.0 problem: USB 3.0 support was actually disabled on purpose because if we turn it on it breaks suspend/resume, and that hasn't changed for final (contrary to what I wrote in my comment). We did, however, document workarounds on the Common Bugs page - https://fedoraproject.org/wiki/Common_F14_bugs#usb_3.0 .

You never replied to my comment that 'release candidate' is a tricky concept when it comes to Fedora, because we have 'release candidates' of the Alpha and the Beta as well as 'release candidates' of the final release. I also asked if you could post the filename and sha256sum of the images you tested so I could confirm exactly what it is you were testing, but you didn't reply to that, either.

It's possible that you really are testing the final release and you're seeing bugs that look exactly the same as bugs that other people saw in the Beta and subsequently confirmed were fixed but are in fact *different* bugs, I guess, but it seems unlikely, and there's no way to tell for sure unless you let us know exactly what images you tested.

But if I could buy him a mac, keep the administrator account for myself, and give him a user account that could only install and run app store apps

Hi, you appear to be looking for one of these:

http://www.ubuntu.org/
http://www.fedoraproject.org/
http://www.madrivalinux.com/
http://www.opensuse.org/

Seriously, we have been able to do that sort of thing for a really long time now with GNU/Linux. That is exactly what I do with my mother's desktop, and there has not been any problems yet.

When a new OS version comes out its around $160 for 5 licenses.

Try this or this - both are $0 for as many instances as your corporately locked-in mind can imagine.

I believe Fedora 13 now has that.

In the blog entry, Mark writes about "... a willingness to chase down the problems that stand between here and there." From my experience, problems are not chased down but rather the Ostrich algorithm http://en.wikipedia.org/wiki/Ostrich_algorithm is applied.

While running karmic (9.10), I noticed a bug with the network-manager pertaining static IP addresses and wireless connectivity, which made it unable to connect to certain configured wireless access points. Lets take a look at the network-manager released with 9.10: http://packages.ubuntu.com/karmic/net/network-manager , it is (0.8~a~git.20091013t193206.679d548-0ubuntu1).

Now lets look at the updates for karmic at http://packages.ubuntu.com/karmic-updates/net/ , there is not a single one (!) for network-manager. For the whole six months until the next release of 10.04, not a single update for it has been provided! They just took the git snapshot and left it in 9.10.

Just compare it to Fedora 12 and their updates on http://koji.fedoraproject.org/koji/buildinfo?buildID=172857 , karmic (9.10) was released at October 29th, and one can see the fixes and updates through Oct, Nov, Dec, Jan for F12.

I do not care about the marketing strategies and public image of Linux distributions, but rather about exactly what Mark said, about " ... a willingness to chase down the problems that stand between here and there."

For me, Ubuntu did not deliver that.

Fedora. It doesn't have in-place upgrades at all

Sure it does. Just use preupgrade. I used it to go from Fedora 12 to Fedora 13.

Y'know, I'm really glad Google wants to provide a new API for managing security. We need somebody to do this for us - somebody who really knows security, somebody who may as well have security as their middle name, to come out with an API framework for Mandatory Access Controls, preferably built right into th operating system kernel of a major distribution.

Yes, I'm really glad Google took the initiative on this.

Or, since they said it is a package, you could just uninstall the package...

Really this isn't much new - Fedora and Debian have had things like these... Debian's is called Popularity Contest, and Fedora is looking at doing the same though I could have sworn they already had that in Fedora...

Luckily, numerous varieties of recovery disks are Freely Available on the internet, or you can build your own if you prefer.

what is wrong (philosophically, security-wise, or wishing leprosy on oneself, etc.) with installing Moonlight

That you may get sued (=Fedora forbidden item).

Actually, there *is* an alternative repository that is 100% binary compatible with the enterprise editions of the distro you refer to. You may have heard of it...
http://www.centos.org

The distro you refer to also has their own totally free Linux distro/repository, which you also may have heard of...
http://fedoraproject.org/

The business model of your example is not simply repository access. What you're paying for with their "main distribution" is easier access to support and updates/patches.

You can get piles of cool stuff for free. Or you can be an honorable, ethical being. You don't get both.

http://www.fedoraproject.org/

You could simply use it as a desktop. Linux has grown leaps and leaps and leaps forward and in many ways ahead of the Mac as a desktop, so read on.

KDE SC 4.5 (about to be released in a few days/weeks) is leaps ahead of the Mac OS X 10.5 GUI. The only catch is that it is not minimalistic. If you want minimalism you have to pick Gnome with Gnome DO and set it to act like a docky. Put a Mac OS X wallpaper in place and install a Mac OS X theme. However KDE has focussed on more minimalism since KDE4 without sacrificing features.

There is a KDE application for video editing that is unparalleled: Kdenlive: http://www.kdenlive.org/
It slaughters Sony Vegas in functionality and is free of charge too. It may not be stable enough yet (version 0.7) so it might be a little bit of a bumpy ride at first.

There is also a kick-ass music management application: AmaroK: http://amarok.kde.org/
It is compatible with iPods that are not of the latest generation (USB encryption crap)

KDE SC's default webbrowser is Konqueror, which, since KDE SC 4.5 also has WebKit support.
Google's Chrome is now also runnable on Linux.
If you don't like the Google privacy stuff than search for the Iron browser (they took the Chrome's source code and stripped it from any call home functionality)

For managing photo's, use DigiKam: http://www.digikam.org/

Personal information management: KDE PIM

For personal finance: http://kmymoney2.sourceforge.net/index-home.html

Office work isn't Linux' best aspect, so you could install OpenOffice.org. It is however the best Office Suit available for the PPC. It doesn't look all that good if your distro of choice hasn't supplied their own KDE4 integration into it.

Now there are a lot of distributions, so what should you pick?
The best and most stable KDE4 distro I have ever tried is Fedora. The default download option is with Gnone so search for a PPC KDE version. Because Fedora core is not using anything that is even remotely patented, you have to go to the RPMFusion website to add Adobe's Flash, MP3 and QuickTime codecs and whatnot: http://rpmfusion.org/RPM%20Fusion

You can see pick your download here: http://mirrors.fedoraproject.org/publiclist/Fedora/12/
The Problem I am seeing here is that the current version of Fedora is 13 and the latest PPC64 builds are for Fedora 12. This leads to a little outdated software (1 year).

Ask any company that hosts an open source software project how many outsiders actually commit code

http://www.fedoraproject.org/

Hm...

Fedora's been doing a pretty decent job of stripping out all of the non-free software. Licenses are a constant issue, and the Fedora Project maintains a long list of licenses that they will and will not accept. There's also their list of forbidden items (not the same as the list of license conflicts), which includes proprietary binary drivers, Flash, Sun Java, Moonlight, and TrueCrypt. Those limitations are the main reason for the existence of RPMFusion (and Livna for libdvdcss).

Fedora's been doing a pretty decent job of stripping out all of the non-free software. Licenses are a constant issue, and the Fedora Project maintains a long list of licenses that they will and will not accept. There's also their list of forbidden items (not the same as the list of license conflicts), which includes proprietary binary drivers, Flash, Sun Java, Moonlight, and TrueCrypt. Those limitations are the main reason for the existence of RPMFusion (and Livna for libdvdcss).

The latest Fedora release, 13, already has Shotwell enabled. And the good package maintainers help getting the experience right the first time, too.

Changes in Fedora for Desktop Users

Close. It wasn't code that was injected, it was proprietary binaries. In other words, closed source kills. Yes, the same general category that gives us billions of lost hours from crappy drivers for good hardware. The same general category that is responsible for providing an incubator for the world's botnets.

That makes what Novell, Black Duck and other branches of Microsoft are doing so profoundly bad when they try to re-label their proprietary binaries 'open source' without releasing the full source. Just releasing some of the source doesn't count, it's as bad as all-binary proprietary. By release, that means read, edit and re-compile. Anything less is just plain dangerous.

You'd think that countries would learn. Or at least the US would learn. As things are, TSA is shaking people down for baby milk instead of doing something useful like nuking each and every NTFS partition on every harddrive that passes through customs. During a transitory period of a year or two, they could take it easy on the scum by just erasing every file ending in .com, .exe, or .dll and handing them a Fedora live CD. Tracking down and locking up the present and former executives of Microsoft and its partners would be another step forward. Off to Gitmo with the lot.

Fedora 13 contains Xen hypervisor and tools, but it doesn't contain rpm package for a Xen dom0 capable kernel. There are unofficial Fedora rpm packages for a Xen dom0 capable kernel, based on the upstream pvops dom0 kernels (Linux 2.6.32). More information about Fedora Xen status and links to rpms see: http://fedoraproject.org/wiki/Features/XenPvopsDom0 . More information about available Xen dom0 kernel options see: http://wiki.xensource.com/xenwiki/XenDom0Kernels .