Some GNU humour (couldn't paste it - Slashdot filters don't like GNU humour)...

http://cvs.savannah.gnu.org/viewvc/*checkout*/emacs/etc/JOKES?revision=1.4&root=emacs

Why the hell would you want to use VM's? It add complexity and overhead. It doesn't even take into account that a database (preferably a redundant one) will likely be required.

A much simpler setup: get heartbeat running between two servers, set up each server to run a web server with floating IP, do the same with MySQL (one master, one slave, configured so that they can both live on the same server) and configure DNS round-robin between the two floating web IPs.

You can probably add LVS on top of that if you wish (still managed with heartbeat) - I don't have too much experience with LVS though.

As you grow, you can add more servers to handle the load and eventually separate the DB and WEB clusters.

True. I've been a bit mislead... There's still a whole lot of domains that will be signed by network solutions though.

Actually his software does not even implement this yet (I guess he's looking to see if it gets traction from the rest of the world first). Besides, I read on an IETF list about people who independently wrote a client and server implementations. It is simpler to implement than DNSSEC in many aspects too.

Well, actually it seems that I relied on confusing information - the truth is that the domain owner has to sign it, it just happens that Network Solutions will be the one signing all .com's and probably a bunch of other ones.

From the namedroppers mailing list (IETF) there have been report of independently built client and server implementing DNSCurve. I alto trust Daniel J. Bernstein to update tinydns & dnscache as required if it gets adopted. Note that Microsft and Apple, who both have a good share of DNS servers out there, do not have a DNSSEC implementation yet.

The implementation is also much simpler than DNSSEC.

Go back to the specs. Every keys has to be signed by Network Solutions, and you must update your signatures every 3 month. If you have >100 domains to manage you sure can understand the pain :)

DNSCurve is a trust chain. You have to trust the root and every server in-between to guarantee integrity. Once implemented from the root to the final authoritative server the trust is complete. It doesn't require any modification to registrar interfaces to managing it though, as all you need is to change your NS hostname (which embeds the DNSCurve key).

Trust is the same for DNSSEc, it's just that instead of using the root servers as a trust chain, you use a 3rd party that every domain owners had to pay for.

I hardly doubt many institutions will actually pay for signing their zones. o me it's more DNSSEC which is a hype and I'm under the impression many people pushing for it just don't know the implications (they just want to secure DNS).

DNSCurve is much easier to implement than DNSSEC and and also advantages in term of cryptography speed and increase of traffic.

DNSSEC rely on having a central "trusted" authority to sign all the dns keys. Not even speaking about the inherent security issues with this model, that means that everyone will depend on a single authority for name resolutions (sure Network Solutions loves this)

DNSCurve is a much better solution in that it offers a trust system without the need of a central authority. The key is embedded in the DNS name server (NS) hostnames which are always returned by the upper level name server.

See http://dnscurve.org/index.html

Err I meant before 2.6.25, the < didn't catch.

'nice' does not affect IO, only process scheduling.

The CFQ scheduler have IO classes with priorities that can be set with 'ionice'. Be sure to use a recent kernel though, I've seen nasty bugs in 2.5.25.

Depending on the typical load type even the IDLE class might be worse than the Deadline or Anticipatory schedulers (they do not support classes even if you can set them) so testing is the key, though for desktops CFQ+ionice should be best in most cases.

The problem is often not compatibility within the same company, but supporting clients and partners that never heard of OOo.

This means that when you send out a document in MS format from OOo, you need to be assured that the other party will see it properly with Office, and you shouldn't spend too much time fixing up documents you receive in MS format.

From my own experience vector art doesn't work within MS application neither!

Every time I used them I ended up with vector graphics offset from their original position, and I quite often seen the same behaviour on documents I received.

If she is, she most likely received a letter too, she just didn't tell him!