Date: Mon, 30 Jun 2008 13:16:11 -0400 From: Jeff Wheelhouse <freebsd-fs@wheelhouse.org> To: freebsd-fs@FreeBSD.org Subject: Re: It's 2008. 1 TB disk drives cost $160. Quotas are 32-bit. Message-ID: <2D2DBAC8-43E2-4AB8-9EEE-44C8304A0E82@wheelhouse.org> In-Reply-To: <20080630085612.G1807@kozubik.com> References: <20080628132632.R1807@kozubik.com> <864p7bw387.fsf@ds4.des.no> <20080630073539.U1807@kozubik.com> <4868FB2F.7010204@FreeBSD.org> <20080630085612.G1807@kozubik.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2D2DBAC8-43E2-4AB8-9EEE-44C8304A0E82>