It's 2008. 1 TB disk drives cost $160. Quotas are 32-bit.

[Jeff Wheelhouse]

I suspect a lot of John's frustration on this issue stems from the  
amount of effort he put into getting it to work before realizing it  
was a lost cause.

I suspect that a lot of that work occurred because the 32-bit  
limitation is not well documented.

Maybe edquota(1) deserves an update reflecting the limitation, so the  
next guy doesn't waste a day?

I have a separate, semi-sarcastic rhetorical question: if John is  
really the only person left using quotas, and he's willing to bite the  
bullet, is backwards-compatibility really that big of a deal? :-)

Disclosure: I don't use quotas (but one of my companies is a customer  
of one of John's, so I assume they affect us indirectly).  That said,  
yes, I'd agree with his statement that quotas are one of those  
features that I would expect to see present and working in a *Nix  
operating system.

The tone of John's message was definitely short in the tact  
department, due no doubt to the aforementioned frustration, but the  
content appears to be this: FreeBSD is the operating system that uses  
"The Power To Serve" as its tagline.  In 2008, 64 bit filesystem  
quotas are a reasonable expectation from a server operating system.   
What will it take to make that happen?

As far as the resulting argument, which is as old as the hills, it is  
fundamental to open source projects.  In my personal opinion, one of  
the reasons people pick FreeBSD over Linux (for example) is because of  
the tighter, more stable, more reliable, less "shiny-bauble"-oriented  
control exerted by the core team.  That's waned, somewhat, out of  
competitive necessity and out of the "well if I can't work on teh  
sexay here, I'll go somewhere else" attitude justifiably espoused by  
people who are doing it out of personal desire.

ZFS is kind of an ugly example of "coreness," because a lot of the  
traffic on this list is devoted to the ZFS deadlocks, crashes and  
other problems that render it suitable only as an "experimental" in  
7.0.  Historically, my impression of FreeBSD is that it doesn't tend  
to put "experimental" and "core" labels on the same feature.  That's  
why I depend on it.

At the same time, there are *thousands* of open PRs on problems that  
have been open for years because the problems, while they may be  
important, aren't sexy enough to attract the attention of people who  
work for free.  If you're trying to run a business and you're hit by  
these types of problems, yeah, it's pretty frustrating.  So are the  
"fix it yourself, if you care so much" and/or "I don't want to fix it  
and you can't make me" responses that inevitably follow, particularly  
if you don't have the expertise to do it yourself or the money to pay  
a developer to do it for you, if you could even find one.

There is a lot of unsexy work that, left to their own devices, nobody  
is ever going to do.  (Which is not to imply that it never happens;  
I'm thrilled and grateful that we finally got a working nullfs after I- 
don't-know-how-many-years.)  It sounds like part of John's frustration  
is that he'd like the core team to take a more active rule in  
convincing people to do that unsexy but important work.

I don't know about him, but I use FreeBSD in a very mission critical  
way.  It is the single most important piece of software we run, but we  
pay nothing for it.  I'm not running any big rich companies but I  
could probably afford a few hundred dollars a month, and I'd be more  
than willing to spend that on a support contract on FreeBSD, similar  
in spirit to what we paid Sun all those years ago, if it would help  
our FreeBSD problems get fixed even when they weren't sexy.  Now I  
don't hold any mistaken memory that having a support contract with Sun  
guaranteed that SunOS bugs/limitations we found automatically got  
fixed, but Sun does/did officially pay people to do work that was  
important but not sexy, and there is an advantage in that.

I know there are all sorts of FreeBSD support offerings out there, but  
I don't believe any of them are "official."  And, as far as I know,  
very few of them go to the level of fixing bugs in the source and  
committing the changes back to FreeBSD.  Those that do seem to charge  
a heftily-inflated per-hour fee to do so.

I also know that there are zillions of ways to financially support  
FreeBSD.  But, like John and like the developers who work for free, I  
am motivated by self-interest.  I want the equivalent of a maintenance  
contract; if I open my wallet, I want that money to go toward  
*maintaining* FreeBSD: fixing what's broke and keeping existing things  
updated, not paying to accelerate new feature development that (a)  
people are already willing to do for free and (b) may or may not  
benefit me.

For something like that, I'd be looking for somebody "official,"  
somebody who cares enough about FreeBSD, cares about its reputation  
(and reality) as a rock-solid bulletproof server OS, someone who uses  
the money that comes in to improve FreeBSD, and not to fund a fancy  
professional consultancy.   Somebody connected enough to know where  
limited funds can make the biggest difference, and to whom they should  
be directed to make that difference.

I don't know if that would be a job for the core team, or the FreeBSD  
Foundation, or who exactly, but it sure would be neat if it were  
*somebody's* job.

Thanks,
Jeff