yum install libpcap-devel

No, it's not on the RHEL6 installation media, you have to have registered the box for RHN.

(RH is really pathetic this way, lots of useful packages are left off the installation media, seems they are forcing you towards satellite, but if you don't have the bandwidth for satellite, or need to setup a box without internet access, sorry for you if you want to something like use oscap - they give you openscap, but not openscap-utils). Oracle is better in this regard, with a public yum repo for release packages (not updates). Of course, CentOS gives you everything, as do all other community-oriented distros.

And the only 'innovation' over similar implementations (such as in Nokia Series 60, available since 2004), is the addition of the word 'touch screen' and 'gesture', in place of 'menu button' and 'click'.

The *exact* method that worked on N950, reportedly worked (by design) on N9.

Aegis does have some value. I don't think N900 was ready for a mainstream audience, there would have been rootkit apps all over. Aegis goes some way to protecting users from malicious apps.

The open mode is implemented, and apparently as of the beta2 for N950 the intended mechanism works. Users with N9's on PR1.0 are reporting that they can boot a minimally patched kernel into open mode.

Really? You mean preventing user apps from doing dangerous things without the user's knowledge is just as open to abuse as allowing everything?

Too many ambitious but clueless users on N900 have had to have their hands held through manually fixing or flashing their devices because they thought installing rootsh was cool. If it had been a mainstream device, I think there would have been a lot of exploits for it ...

Since the N9 was intended (until Feb 12) to be a mainstream device, it really wouldn't have been a good idea to have gone with the totally open mode of N900.

Or, Kindle app (or any other e-book reader if you have epubs) on a smartphone which has TV out of some kind (A/V or mini HDMI or MHL), then the touch screen can be used to navigate pages.

Maybe first Facebook can support displaying existing comment fields and meta-data on photos like some other photo hosting sites.

Have you tried recent kernel-power releases?

How do you know the overhead of dm-crypt will actually have any noticeable impact on your N900's performance?

My N900 with CSSU has been performing quite well for the past month, but I'm not currently running kernel power.

One howto is here, but due to framebuffer not working in the titan kernel is not complete ... and you need a non-stock kernel for dm-crypt (apparently, I wonder if it is possible to build just dm-crypt and dependencies for the stock kernel).

They showed that it is possible to control the printer as well, so then it would depend on what is printed by the printer, and whether voters would notice.

And how much of that comes from vending/supporting "their" software (vs. selling hardware and taking cuts of everyone else's content and software that is sold via their "store")?

No. This is a vulnerability in the client-side portion, as if you had configured a linux client with:
auth sufficient pam_permit.so

It should have no effect on any other clients.

Firstly, this vulnerability has nothing to do with the LDAP server, or owning the LDAP server. It is effectively as if Mac OS X, when configured for LDAP authentication, has a 'auth sufficient pam_permit.so', so the client will accept any username or password. However, this doesn't imply any access to the LDAP server ...

I have a few, where Kerberos is not really viable, and (since almost all access to anything is via ssh with public keys - but stored in LDAP), the passwords aren't really the issue, but the ssh public keys could be replaced ...

Why would it be any less awkward than Kerberos (besides the actual SSO part, but if you're not actually doing GSSAPI auth anywhere after login it is irrelevant)?

Almost all Linux distros have tools to configure a box for LDAP authentication, most of them get it right to set 'passwd' up so that it works correctly ... even if you didn't have that, you could use 'ldappasswd' to change your password (but, it is probably a bit too inconvenient for most users).

However, if you have password policies configured (e.g. with slapo-ppolicy on OpenLDAP), and users log in to a display manager, they would be prompted to change their passwords on login (without having to touch the command line), just like you could do with Kerberos.

Long-time Mandrake, Mandriva and now Mageia contributor here ... I would warn you that in the past, a lot of server-related packages were maintained by the community (apache and php being about the only ones maintained by one over-worked employee). For a number of reasons, a lot of those contributors have become disenfranchised with Mandriva, and have been porting their work over to Mageia. Thus far, my packages are still in sync between the two, but recent events have been motivating me to rather consolidate my work on Mageia:

• New Mandriva employees making significant (bad) changes to packages which are officially maintained by a community contributor, without consultation.
• Lack of communication with contributor community, with sudden changes to the release plan (one month prior to the planned release, and after the original RC date - which is usually when version freeze kicks in - the release was moved out by 2.5 months). This makes it quite difficult for contributors to plan their contributions (e.g. I put some effort into getting my packages up-to-date for the May freeze date - during times when I had lots of other responsibilities - only to have my effort effectively wasted).
• Lack of commitment to support of development infrastructure - there appears to be little internal support for the development infrastructure, contributors have been doing a lot of the work of maintaining the build cluster, and when they aren't available, it is often off-line for days at a time. In addition, there has been conflict with some of these contributors, so they are now resentful of being the only support for the build cluster.
• Animosity by the RPM5 protagonists
• Lack of effort in supporting the traditional (non-Live-rsync-all-files-to-disk) installer, which is critical in any server-focused environment. Apparently it still works, but if there are bugs they probably won't be addressed.

These issues seem to not be affecting Mageia much, so now that 2011 is out, and I will be forced to decide between Mandriva and Mageia for my own uses, I will probably be upgrading all my Mandriva 2010.1 machines to Magiea, and will probably move all my effort to Mageia and orphan my Mandriva packages (like many other contributors have done). The current focus of Mandriva is not sufficient for my own uses, so I believe my contributions will be of more value to myself in Mageia than Mandriva.

Note to all users considering Mandriva 2011, note that while an upgrade to Mandriva 2011 should be relatively painless, a later crossgrade to Mageia will not be (due to the RPM5 switch in Mandriva 2011), while a cross-grade from Mandriva 2010.1 to Mageia should also be as painless as upgrading to Mandriva 2011. So, while I won't tell you to ditch Mandriva, you should pause at this stage to decide if you are currently on Mandriva 2010.x.

This story is about LibreOffice, not OpenOffice.org. In LibreOffice (3.3.2) on Windows 7 x64, I don't have this problem ...

And Nokia's problem so far has been having too few models? And they're biggest competitor launches how many phones a year?

It is evident from a number of sources that are or were inside Nokia that Meego/Harmattan was delayed due to continual direction changes by management. I believe Meego/Harmattan, if it had been shipped by February 2011, even with 1 device a year, would have been sufficient to make Nokia's Qt strategy successful.

But, too many devices leads to a lack of hardware accessories from 3rd parties, too many form factors for developers to consider (right, Qt/QML would make it easy for most apps), too much divergence in software between devices, leading to fewer updates, leading to shorter support lifetimes, leading to resentment from customers, leading to smaller market share.

I think Nokia still hasn't managed to figure out what it is that they are doing wrong. It certainly wasn't their Qt strategy, or Linux-based devices, or tablets ...