Slashdot Mirror

Ever since Ubuntu Edgy much of the low hanging fruit in speeding up the Ubuntu boot has already been taken. Looking at the bootcharts for my system since then shows remarkably little time when the CPU is idle once the base kernel has finished loading. This means that running anything more in parallel simply won't net me anything (in fact scheduler overhead and disk thrashing may in theory make things slower).

For example, there is an improvement in the time it takes for the clock to appear from "Ubuntu Dapper Flight 3 Default kernel" to "Ubuntu Feisty Herd 5 generic kernel". The Ubuntu folks worked hard to try an eliminate sleeps from their initscripts and when a sleep was unavoidable they would run other parts of the startup process in parallel. They also made changes to Xorg to prevent it (re)reading so much stuff on launch. There was also the introduction of the readahead script which tries to arrange for as much of the boot time reading to be done in one big chunk. Throughput is higher when the disk is only reading and can utilise it's readahead. An attempt is also made to try and request files in the order in which they are laid out on disk (to minimise disk seeks which hurt performance). In Feisty a move was made to using dash instead of bash for scripts because it was smaller and executes scripts faster.

The only things that seem to win me any gain over the default Ubuntu Feisty install are turning off initscripts for services I absolutely won't use (e.g. ipv4 autoconfig via avahi) and reducing the number of restricted binary driver modules being probed (I have long noticed that the only benefit that recompiling the kernel gives to boot speed is that you can simply leave out features not on your computer making the initial kernel startup where it probes for things you might not have (like which software RAID is faster) a shade faster). It is also worth noting that Ubuntu starts X quite early and continues loading services afterwards which means the gain from disabling one of these "after X" services (like CUPS) isn't so noticeable (but might mean your desktop actually starts responding to clicks a bit sooner).

Profiling the boot to try and improve the readahead takes a long time to run - the profile run seems to take three times as long as a regular boot. It could be argued that you will never gain back the extra time you waited on the profile run...

I suspect reducing the boot further will start to need more complicated procedures, perhaps reordering modprobe.conf and reducing the amount of needless reading of files. Eventually you end up having to do the same tricks as Windows/OSX - e.g. working out where the fastest part of the disk is and copying every file needed to boot there, bringing up the network cardafter the desktop has started, periodically defraging bits of the disk, prelinking...

Your comment about "Joe User" is accurate ... but premature.

The group that will initially drive Linux adoption (whether *buntu or other) will be governments and businesses.

The majority (99.9%+) of workers in those two categories will not be focused on the latest hardware and toys. They use wired connections, 2D graphics and save their data onto a central server. Their users do not maintain nor upgrade their boxes. They have experts who do that for them. And being Debian-based, *buntu is very easy to upgrade/maintain.

The only features missing for those categories are email / calendaring / scheduling (similar to Outlook/Exchange, GroupWise or Lotus Notes) and directory services (similar to Active Directory or eDirectory). The directory services may be here soon from Red Hat's Directory Server http://www.redhat.com/software/rha/directory. But the email segment is taking a bit longer. Eventually that will be here also.

At which point, non-US governments will be heavily pushing to get off the Microsoft upgrade treadmill. Particularly since they'll be able to invest in their LOCAL developers to polish Linux for their specific needs.

As the government / business workers gain familiarity with Linux at work, they'll be more comfortable using Linux at home. But the home market will be the LAST market that Linux will crack. And it will take YEARS (literally).

If you want to bring the home market around quicker, you need to focus on bringing WINE up to speed for their applications (and the home users have a LOT of different apps, each with slightly different requirements and almost NONE of them written in an easily portable fashion). Or you can work on near identical apps for them (which addresses your point about them "learning" by rote).

About marketing; while marketing OSS is a process in itself, some projects do have marketing materials available, just have to know where to find them. Then have to take some time to pick out what works and what doesn't. Examples: http://marketing.openoffice.org/ , http://www.ubuntu.com/products/casestudies , http://www.redhat.com/solutions/intelligence/

Finally, don't see why this is on the front page. This is a question to the public, not news. Take it to a freakin forum.

Here you go: http://ftp.redhat.com/pub/redhat/linux/enterprise/ 5Server/en/os/SRPMS/

I started reading that article, that is linked from the story without checking the url and as my eyes were just openning wider and wider with each false claim and each line of FUD I finally reached the point where I had to know who the hell wrote it and so I look up into the address bar and I see www.sco.com

Pheew! Geez whiz, so as my blood pressure normalizes I just wanted to ask /. staff: PLEASE mark the SCO articles in a more visible manner, it's dangerous for health to read such tripe. Also can't we sue SCO for libel or something?

I mean this is actually false information, they are knowingly lying to everyone with each breath they take.

Just read this:

However, there is a group of software developers in the United States, and other parts of the world, that do not believe in the approach to copyright protection mandated by Congress. ...
The software license adopted by the GPL is called "copy left " by its authors. This is because the GPL has the effect of requiring free and open access to Linux (and other) software code and prohibits any proprietary use thereof. ...
This stance against intellectual property laws has been adopted by several companies in the software industry, most notably Red Hat. Red Hat's position is that current U.S. intellectual property law "impedes innovation in software development" and that "software patents are inconsistent with open source/free software." Red Hat has aggressively lobbied Congress to eliminate software patents and copyrights. (see http://www.redhat.com/legal/patent_policy.html ).

I mean can't Red Hat for example sue them for libel? SCO is constantly insisting that GPL is anti-copyright, while GPL is only possible because of copyright law. They are misstating what GPL is about too by insisting that GPL does not allow any proprietary use (GPL requires that a distributor of GPLed code, follows GPL procedures, this is not about use.)

Red Hat has aggressively lobbied Congress to eliminate software patents and copyrights.

Copyright © 2006 Red Hat, Inc. All rights reserved.

but they no longer offer the policy sources since 3 (maybe 4)

So what do you call this ?

The selinux-policy-devel, selinux-policy-targeted, selinux-policy-strict, and selinux-policy-mls packages are all created from the above linked source package. You might only need the -devel package.

Walking around their site and bumped into the docs section. https://www.redhat.com/docs/manuals/enterprise/RHE L-5-manual/release-notes/RELEASE-NOTES-x86-en.html

i have to agree actually. i've been playing and rhel5 is actually a pretty nice os. i like ubuntu, but after the last release fiasco, and my company suffering a few DAYS of downtime because of ubuntu, we're seriously considering switching to Redhat. this release so far has made me happy from what i've seen and i just looked at their support options and find out the support actually might be worth looking into http://www.redhat.com/promo/vendor/ can't really beat that!

Why, of course, here you have a link to Red Hat RHEL 5 sources.

They don't give you the compiled iso image, but the sources and modifications are there. But notice that even then it's NOT freely redistributable - you've to remove the redhat copyrighted contents (ie: red hat logos/name in the desktop background, installer, etc). The source code is there though, hence the comply the GPL, and the contribute back to the community (fe., red hat is the main contributor to linux kernel - glibc - gcc)

> And if you're using RHEL for a desktop system, for any
> reason other than being able to test things before deployment,
> you should have your head examined.

Actually there are few more reasons to use RHEL (or maybe deriatives like CentOS) on workstations.

http://www.redhat.com/rhel/desktop/

Okay, someone look at the official announcement... er, official "thank you" page for RHEL 5, and watch the embedded video.

Then tell me someone at Red Hat hasn't been playing too much Katamari Damacy.

Fedora Core (what Red Hat is based on; I also believe released by the same group) is free, for the exception of the wopping five CDs it needs for installation.

http://fedora.redhat.com/

You can download Fedora from there.

I'm sure there are 'ways' to get this version free, however I 3 the company so much I wouldn't have the heart to do it.

Let's take indemnification; this should be a topic every company should suddenly be looking very closely at. Microsoft just got nailed with a whopping $1.53 Billion, that's with a "B", judgment for the use of a common music standard. They did this because they indemnified Dell and Gateway, the companies initially targeted. If they had used Linux instead of Windows, it would be Dell and Gateway hit with some fraction of this judgment (and even a fraction of $1.52B is a big number). So where is the coverage? Don't you think it should be a hot topic right now, so where is the chatter?

Are you just making shit up? Red Hat released 2.1 during the first half of 2002 and will support it until 2009. Just over seven years of support there.

For those who are interested here are the release notes. The technology preview is particularly mouth watering. Personally I'm especially looking forward to GFS2.

The RedHat KB explains it:
http://kbase.redhat.com/faq/FAQ_41_9949

The old glibc included the timezone tables. Newer releases have broken timezone into its own package.

If by still struggling you mean by, "only being available in every Red Hat (Enterprise) Linux since Red Hat 7.2", perhaps.

There is both netdump (dump to a remote host, via ssh), diskdump (dump to a partition) and the new to be in RHEL5 kdump (which does all kinds of neat things).

and re: debuging tools:

Its not for kids, but check out andersons paper on debugging vmcore files.
http://people.redhat.com/anderson/crash_whitepaper /index.html#toc

I've traced down a few causes of bugs with this, One might argue it might not be as point and clicky as other crash debuggers, but I'd rather have a skilled coder fixing bugs than someone who feels uncomfortable at the commandline.

RHEL is certainly a distro that is aimed at stability rather than the latest features. It is Red Hat's policy that they will not upgrade any package past the minor version that originally shipped with that release. So if it shipped with Python 2.2.3 then it will never go past 2.2.x. They will backport security or stability patches from later releases if necessary.

If that's not the policy you're looking for in a distro, then RHEL is not the distro for you. That said, I have had lots of luck in compiling SRPMs from later RHEL versions or from Fedora when necessary. For example I wanted to upgrade my CentOS 4 box to PHP 5, so I just grabbed the latest php-5.2.x SRPM and was able to compile and install it without much modification (I believe I had to take out a not-yet-supported gcc option and a couple other tweaks).

Going that route IMO is a good mix of stability and being able to upgrade certain packages when necessary, because the SRPMs already include Red Hat specific patches when necessary, but if that method is still too far from the bleeding edge for your tastes then I would agree RHEL is not a good match for you. That doesn't mean there's anything wrong with RHEL though.

RHEL and ubuntu cater to two completely different kinds of computing.

Ubuntu cares more about pretty widgets for new linux users than "Enterprise" features.

By "Enterprise" I mean things like...

Kerberos/LDAP integration: If you don't know, this is what will enable SSO capabilities. (aka, what windows did with AD over 7 years ago.) Ubuntu has had a bug in nss_ldap that showed up in Edgy that causes the system to delay booting by a few minutes because it "cannot contact the LDAP server".(bug Bug 51315). Dapper was supposed to be the first Enterprise edition. It worked fine in that release. It has been broken in Edgy, and will remain broken in Feisty as well because its part of "Universe" and not in the main branch. Something like this should not be broken for over a year solid spanning two releases.

Consistency and uniformity: UID and GID used for system accounts (proxy, cups, bin, sys, etc) should not change between releases breezy -> dapper). Whiskey, Tango, Foxtrot.

Commercial software validation/ certification: Oracle support on Ubuntu == Lies.

Documentation: http://www.redhat.com/docs/ vs http://www.ubuntu.com/support/documentation : You decide.
A WIKI??

Support: Redhat will fly somebody out at 3am vs canonicals... uhm.... *reads their webpage*... *scratches head*....

RHEL runs machines that are important.
Ubuntu runs yours.

-s

/ never posts on slashdot... // Posting as AC because I'm too busy to recover my login.

I do not know if it will fit your requirements, but redhat does have solid crash dump support. While it's a little old, http://www.redhat.com/support/wpapers/redhat/netdu mp/ describes it, including it's ability to do crash dumps over the net. A nice feature that comes with the enterprise level versions.

Funny thing about the 'act' that was passed is it has a clause about congressional review. So at some point, congress could have said "This is stupid" and undone the DST change. Everyone was waiting for the fall session to start, I suspect, to ensure the DST change was going to stick.

Further, if your running Solaris it's not just a TZ patch. There's libc changes:

http://src.opensolaris.org/source/diff/onnv/onnv-g ate/usr/src/lib/libc/port/gen/localtime.c?r1=1138& r2=0

There's also glibc issues in RHEL 2.1 but they're not quite the same as Solaris.
http://kbase.redhat.com/faq/FAQ_41_9949

Cheers,
Rich

Once updated, any application relying on /etc/localtime will need to be restarted. The easiest solution would be to reboot the system to ensure that all applications have been updated.

O RLY?

I'm typing this post on a Dell D820 with SuSE 10.2 and 4GB of RAM.

As for more than 4GB, I'd just build a portable desktop. Even with this laptops 4GB of RAM, it can only release just over 3GB due to PCI needs, etc. You might just be better off running a persistent desktop on a server and VNCing/RDPing to it.

What if the price differnce is spent in making sure the linux works on everything? I mean Dell forks a Distro, setd up maintainers, brands it themselves and you have the option of Dell linux or MS windows for the same price?

Of course what you do have is a rescue environment on the install media which you can use to reinstall the package you messed up, either by doing a chroot into your install, or by passing --root to rpm to get it to install onto the hard disk. I've done this several times and its a simple and quick way to get yourself out of the hole you dug.

And this was indeed pointed out here, where, to spare the /.er I quote:

"If I understood this, you deleted something down /lib that rpm depended on. That's not unrecoverably screwed: you can boot into the rescue CD and bring over the libs or the rpm the libs came from and use rpm2cpio. I have done this in the past, and recovered from it, and my assessment of the proximate cause of the failure was that 1) I was a careless idiot.

RPM being monolithic would help in that situation, but then it's open to you to delete rpm if you're up for deleting shared libs. Likewise Ubuntu is going to have things that can be deleted that will render it equally "unrecoverable". Basically there isn't much to be done to protect a tired or stupid admin using rm as root on important files: but the recovery boot is there to get you out of even very bad trouble. I don't think we should entirely absolve the wielder of the rm machete from blame even if he didn't ask to be swinging it about."

Keywords like -force are there for a reason. They're intended for use by someone who knows what they're doing. The system didn't force ESR to use them, it simply was the case that ESR didn't know what he needed to do and used the wrong "system override" to try to do it. Ordinary users would, quite simply, never have destroyed their system in the way ESR did, because of some limitation being imposed by their system.

I left RedHat when upgrading (IIRC) glibc-386 on a 686 system rendered the system unbootable. No warnings, no errors, just a trashed setup.

I think it was probably this bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi? id=88456 but it was a while ago now.

Tim.

Keywords like -force are there for a reason. They're intended for use by someone who knows what they're doing. The system didn't force ESR to use them, it simply was the case that ESR didn't know what he needed to do and used the wrong "system override" to try to do it. Ordinary users would, quite simply, never have destroyed their system in the way ESR did, because of some limitation being imposed by their system.

It's a little like someone thinking that the way to change the root password is to vi /etc/passwd and insert "secret123" in the second column. By the time they're realized they're not the expert they thought they were, it's too late. And the real answer was to use the "passwd" tool. Why did they do it? Maybe there was a bug in the OS. Perhaps "passwd" didn't work, and so they edited /etc/passwd instead. But why the hell would they edit it? Why not report the problem and let someone who knows what the actual issue is get them the fix?

Alan Cox actually does a reasonable job of explaining why ESR has, essentially, blamed the wrong people for this here. There was a problem. Instead of ESR asking for help, he blindly used the sledgehammer to try to fix the issue himself, despite not knowing what the problem was and what the consequences would be of him using the sledgehammer.

Realistically, I don't think this has anything to do with ESR having a package management meltdown. On some level I suspect ESR knows full well that an ordinary user would never have pulled the same stunt he did, and that he bears the consequences for screwing with something he really didn't know enough about. I think this has to do with being frustrated and "out of love" with Fedora, in much the same way as marriages often break apart supposedly because He never passes the sugar, or She never makes the tea. Ubuntu? Well, of course, it's different, it's popular, and it's populist.

I just don't see the need for press attention over it, or the drama queen act.

What are you saying? Will your system still boot if you something like this?

$ rm /lib/libc-2.5.so
$ rm /boot/initrd-2.6.19-1.2911.fc6.img

Does that make the 'rm' command 'fucking stupid'?
ESR has dodged a few questions. Go read https://www.redhat.com/archives/fedora-devel-list/ 2007-February/msg01006.html the whole thread. No one forced him to do stupid things. He chose to do the stupidest possible thing and you didn't take time to understand it. Your comments are uninformed, inflammatory and spread FUD. Perfect for a moderation of "Score:5, Insightful"

..having my brane eaten.

http://www.redhat.com/archives/fedora-devel-list/2 004-May/msg00104.html

I never quite understood this; can't you compile FF2 on your Fedora?

Yes, I suppose I could do that, or I can grab a development rpm version, but that isn't the point. FF2 has been out for a couple months now and is quite nice and stable.

Instructions here

Reasons here

Legal reasons and upgrade to FC7 reasons are what's in the way, and the FC team feels that FF2 should really have been FF1.5.1 and it was just a marketing ploy to rename to FF2.

I don't want to run FF2 in parallel to FF, I want my system to have FF2 on it.

I disagree with the maintainers here, and I've been mulling a move to Ubuntu because of it.

I'm not very impressed with Alan Cox's response, especially considering he sent it from his redhat.com email address.

That sort of rudeness is not needed between a representative of a major open source company and its customers/users. It doesn't matter how much Alan has contributed to Linux, or how much he dislikes ESR, or how much he supports Fedora Core. His response was not needed, and reflects badly on himself, Red Hat, and Fedora Core.

ESR isn't the only person who has experienced some pretty serious problems with Fedora Core. There are many users who have noticed that it is having QA problems. Maybe Alan Cox should listen to what ESR is saying, and address the technical issues. These sorts of personal spats don't help anyone in the open source community.

He's responded a few times already.

Here's the actual mailing list thread: https://www.redhat.com/archives/fedora-devel-list/ 2007-February/thread.html#01006

Here are ESR's responses from that particular thread:
https://www.redhat.com/archives/fedora-devel-list/ 2007-February/msg01060.html
https://www.redhat.com/archives/fedora-devel-list/ 2007-February/msg01082.html
https://www.redhat.com/archives/fedora-devel-list/ 2007-February/msg01097.html
https://www.redhat.com/archives/fedora-devel-list/ 2007-February/msg01118.html

He also started another mailing list thread called "Core Values" which I'll let you find in the mailing list index, which I've linked to already (albeit anchored to the beginning of "Goodbye, Fedora").

He's responded a few times already.

Here's the actual mailing list thread: https://www.redhat.com/archives/fedora-devel-list/ 2007-February/thread.html#01006

Here are ESR's responses from that particular thread:
https://www.redhat.com/archives/fedora-devel-list/ 2007-February/msg01060.html
https://www.redhat.com/archives/fedora-devel-list/ 2007-February/msg01082.html
https://www.redhat.com/archives/fedora-devel-list/ 2007-February/msg01097.html
https://www.redhat.com/archives/fedora-devel-list/ 2007-February/msg01118.html

He also started another mailing list thread called "Core Values" which I'll let you find in the mailing list index, which I've linked to already (albeit anchored to the beginning of "Goodbye, Fedora").

He's responded a few times already.

Here's the actual mailing list thread: https://www.redhat.com/archives/fedora-devel-list/ 2007-February/thread.html#01006

Here are ESR's responses from that particular thread:
https://www.redhat.com/archives/fedora-devel-list/ 2007-February/msg01060.html
https://www.redhat.com/archives/fedora-devel-list/ 2007-February/msg01082.html
https://www.redhat.com/archives/fedora-devel-list/ 2007-February/msg01097.html
https://www.redhat.com/archives/fedora-devel-list/ 2007-February/msg01118.html

He also started another mailing list thread called "Core Values" which I'll let you find in the mailing list index, which I've linked to already (albeit anchored to the beginning of "Goodbye, Fedora").

He's responded a few times already.

Here's the actual mailing list thread: https://www.redhat.com/archives/fedora-devel-list/ 2007-February/thread.html#01006

Here are ESR's responses from that particular thread:
https://www.redhat.com/archives/fedora-devel-list/ 2007-February/msg01060.html
https://www.redhat.com/archives/fedora-devel-list/ 2007-February/msg01082.html
https://www.redhat.com/archives/fedora-devel-list/ 2007-February/msg01097.html
https://www.redhat.com/archives/fedora-devel-list/ 2007-February/msg01118.html

He also started another mailing list thread called "Core Values" which I'll let you find in the mailing list index, which I've linked to already (albeit anchored to the beginning of "Goodbye, Fedora").

He's responded a few times already.

Here's the actual mailing list thread: https://www.redhat.com/archives/fedora-devel-list/ 2007-February/thread.html#01006

Here are ESR's responses from that particular thread:
https://www.redhat.com/archives/fedora-devel-list/ 2007-February/msg01060.html
https://www.redhat.com/archives/fedora-devel-list/ 2007-February/msg01082.html
https://www.redhat.com/archives/fedora-devel-list/ 2007-February/msg01097.html
https://www.redhat.com/archives/fedora-devel-list/ 2007-February/msg01118.html

He also started another mailing list thread called "Core Values" which I'll let you find in the mailing list index, which I've linked to already (albeit anchored to the beginning of "Goodbye, Fedora").

Yeah, and two replies deep -- after one anti-socialist rant -- gets you to this:

https://www.redhat.com/archives/fedora-devel-list/ 2007-February/msg01083.html

That is a telling thread and validates part of what Eric is saying:

"After thirteen years as a loyal Red Hat and Fedora user, I reached my
limit today, when an attempt to upgrade one (1) package pitched me
into a four-hour marathon of dependency chasing, at the end of which
an attempt to get around a trivial file conflict rendered my system
unusable."

Flat out, that should have never been allowed to happen. The fact that it can, and did, highlights what is a fundamental problem with package management on Fedora/Red Hat.

ahhhhh.... stupid reddit linkjacked URL. Now I've linkjacked a linkjacked URL. For the paraniod, the real URL should be https://www.redhat.com/archives/fedora-devel-list/ 2007-February/msg01021.html

The fedora-devel-list has already responded to this, as well as Alan Cox himself.

Personally, I'd like to see ESR's response to these rebuffs.

Risk Impact: High
Systems Potentially Affected: All PCs

Behavior:
Windows.vista is malware that gobbles up all resources on a machine and renders it unusable. Suggested solution is to visit the following malware cleansing site : http://fedora.redhat.com/

Unfortunately, it's not even close. A couple things that spring to mind:

AFS servers don't automatically ensure that every piece of data is stored on some minimal number of them. Enabling/configuring replication of a given volume is a manual process.

AFS treats a single server as the "master" read-write copy; replicated copies are read-only.

Redhat's Global File System ( http://www.in.redhat.com/software/rha/gfs/index.ph p3 ) or Lustre ( http://www.lustre.org/ ) or maybe ddraid ( http://sources.redhat.com/cluster/ddraid/ ) sound much closer to what googlefs is than AFS does.

IMO AFS is more of a file sharing protocol (like NFS or SMB) than googlefs.

Unfortunately, it's not even close. A couple things that spring to mind:

AFS servers don't automatically ensure that every piece of data is stored on some minimal number of them. Enabling/configuring replication of a given volume is a manual process.

AFS treats a single server as the "master" read-write copy; replicated copies are read-only.

Redhat's Global File System ( http://www.in.redhat.com/software/rha/gfs/index.ph p3 ) or Lustre ( http://www.lustre.org/ ) or maybe ddraid ( http://sources.redhat.com/cluster/ddraid/ ) sound much closer to what googlefs is than AFS does.

IMO AFS is more of a file sharing protocol (like NFS or SMB) than googlefs.

Not to mention https://bugzilla.redhat.com/bugzilla/show_bug.cgi? id=119185 which is still not really fixed.

Actually, I think they were referring to this: http://sources.redhat.com/ml/libc-alpha/2000-08/ms g00053.html

It feels like KDE applications take a tiny bit longer to start than the equivalent Gnome app

I think using a *specific* language for automatic parallelization is the wrong way. Some GNU folks are working on language independent autoparallelization for GCC 4.3. Their implementation is an extension to the OpenMP implementation in GCC. Read OpenMP and automatic parallelization in GCC, D. Novillo, GCC Developers' Summit, Ottawa, Canada, June 2006 http://people.redhat.com/dnovillo/Papers/ for details.

Ok. Yes. It was inevitable...
(So mod me an AC Troll, if you like.)

They're still good solutions for this perniscious problem.

http://www.ubuntu.com/
http://fedora.redhat.com/
http://www.mandriva.com/
http://www.debian.org/

or any other flavour of choice:
http://distrowatch.com/

You can even try CD-based versions to see how you really like it before touching a thing on your current system:
http://ubuntu-releases.cs.umn.edu/6.06/
http://www.knoppix.com/

__________

Booting your machine from a CD or DVD ISO to try it out - free.
Selecting your Open Source OS of choice, installing it, and using it however you like - free.
Discovering that, for most things*, it just 'works', will never blue-screen again, and that you've escaped the Microsoft lock-in treadmill - priceless.

* seriously folks, if you want esoterica, it's there too, and yes -- as with all things -- 'your mileage will vary'. But for sane and reasonable interpretations of 'most' this is still true, and not an exaggeration.