On Feb 22, 2011, at 12:57 PM, Peter Jeremy wrote: > On 2011-Feb-22 02:50:54 -0800, Devin Teske <dteske_at_vicor.com> wrote: >> That's the operative word here ("supports"). Lord help us when that >> changes to "requires" (that is to say, if/when the FreeBSD kernel >> becomes legacy-free with respect to supporting fdisk/disklabel >> partitioned disks). > > When that does come, it will probably be driven by BIOS and hardware > vendors dropping support for MBR. Current disks are at the upper > limit of what MBR can be support (and that's after several revamps of > MBR). Since GPT already provides a superior feature set without MBR's > limits, the next step will be to just drop MBR support. And when it > does come, FreeBSD needs to be ready with an installer that can cope > with non-MBR disks. All very true. Though admittedly we're [as a technological society] still a long long ways off from dropping support for MBR in even the most modern BIOS'. > >> We've yet to see a "must have" technology that would require us to >> shun sysinstall (as explained earlier, we have no desire whatsoever >> to boot from ZFS, gmirror, geli, GPT, or anything else missing from >> sysinstall). > > Whilst _you_ might not be interested, lots of other people _are_ > interested in using these features - I personally use a mixture of > gmirror, GPT and ZFS root on different systems. Excellent. And the likes of us (enterprise) will be watching the likes of you (non-enterprise) for many years to come to see how you fare in your travels. From time to time we'll be checking in on the list and perusing list archives to see how well you fare. I don't know if you remember, but I can remember 10+ years ago when ReiserFS (the *killer* filesystem -- sorry, I couldn't resist) hit the Linux scene. There were wild reports of comprehensive data loss even in the 3rd year of its production cycle. It was stories like that which kept down the rate of adoption because many enterprises adopt the same "wait and see" attitude. We call it the "great shake out" and all new technologies must have one before being adopted by the largest enterprises. > Why should other > people be forced to avoid these features just because you don't use > them? They shouldn't. We encourage others to dive head-long into the soupy mix and be our guinea pigs for us. Innovation is no place for the enterprises that run the market place (or even the World). (in a very serious tone) Would you rather your bank call you up and explain that because they tried some new technology that caused a crash in the data center, you won't have access to your bank account for the next few hours whilst they reboot the master server? Just as I suspect your answer would be no, it should be self-evident that when a critical system goes down, there is not always the luxury of being able to drop to gdb/kdb and diagnose the root-cause (rather, disaster recovery procedures often demand focusing your efforts on getting said service -- if not the original machine, a replacement machine -- back online as fast as humanly possible). Whereas others may have the luxury of providing backtraces, core dumps, and swapfiles to the authors of some new kernel device driver to eventually have some critical bug fixed, the downtime required to cull those resources would decimate any profit-driven business model which relies on service uptime. It's very easy to forget that -- while playing with new technologies is both fun _and_ exciting -- businesses that make the world go-'round demand more than just the promise of stability, they demand the numbers to prove it (and even then, may still require their own engineers to perform an "in-house bake-out" of their own which involves the added complexity of working with their own code). Rolling in any replacement anytime anywhere requires "burn-in" metrics to show that the technology can reproduce an acceptable fault-to-performance ratio. Of course, it goes without saying that said stringent testing requires both resources and man-hours. > FreeBSD's installer should support the same features as FreeBSD > itself for consistency. I don't disagree. That's a laudable goal for all Operating Systems. Though with due respect, I don't think any one installer for any operating system allows you to achieve all permutations of which the OS itself supports. > >> pedestals... why would we ever need >8GB for the operating system? >> all production data is being stored on enterprise class devices such >> as the NEC-D210, and being backed up with tapes such as LTO; > > Not everyone uses FreeBSD in the same environment as you. Oh how society would stagnate if we _did_. Thank goodness we _don't_ operate in the same environments (for your sake and mine). > >> We're no stranger to putting even the Operating System on Life >> Support for as long as it takes for our customers to bolster their >> budgets for an integrated upgrade strategy. > > Given that you've already said you are staying with FreeBSD 4.11, We are migrating to FreeBSD-8.1 this year and plan to do so with sysinstall. The whole point about this thread is, that we plan to use sysinstall for FreeBSD-9 and later too. I simply can't be bothered to migrate thousands of lines of code (which are the culmination of multiple man-years) to a new installer that is not vetted in-house yet -- and because at least 3 other people on this list have expressed interest in our life-support for their own enterprise organizations, I am pressing forward with the minor effort that-it-is to make our work public. You question the expenditure of resources whilst we question the decision to completely dump such a tried-and-true technology. A better decision would have been to offer both sysinstall _and_ bsdinstall in FreeBSD-9 and then offer only bsdinstall in FreeBSD-10 (it even has a nice mental picture to it ... FreeBSD-10 being the legacy-free installation method). Personally, I find the immediate jump to be rather maligned from the spirit of enterprise development. > why are you at all worried about FreeBSD using a new installed in > FreeBSD 9 to support features that don't exist in FreeBSD 4? You misunderstood the entire thread. We are migrating from FreeBSD-4 to FreeBSD-8 this year and have already migrated thousands of lines of code from RELENG_4 to RELENG_8 last year for the big-jump. This thread was created because it was announced that RELENG_9 will surreptitiously drop sysinstall completely in favor of bsdinstall without so much as a "honeymoon period." > FreeBSD is primarily a volunteer project. Whilst you may be an expert > on the innards of sysinstall, this seems to be a rare skill and no-one > (including yourself) has stepped up and offered to add the missing > functionality to sysinstall. Innovation is bourne-of necessity -- and we don't need said "missing" functionality. sysinstall is fully-featured for us. Though, the answer you're looking for is likely one of the following: (a) We are the only people in the World skilled enough make these additions to sysinstall (and we've made our stance very clear... that it would be a waste of our time to make such additions because we don't use these technologies). (b) There are other people in the World capable of making these additions, but they hold the same views. (c) There are other people in the World capable of making these additions, but they would rather funnel all changes into a new product, avoiding destabilization of sysinstall. All other people (those that are not well-versed enough to add these features to sysinstall) fall clearly into two camps: (1) They'd like to see the additions made to sysinstall, but simply don't know how to go about doing so. (2) They simply want to see sysinstall die for its iniquities. The latter group perhaps representing the majority of opinions that I've observed in the past few months on this (and other) lists. But, I assure you that the reason that sysinstall has not had these additions is more likely due to the fact that anybody/everybody that _is_ comfortable with adding to the current state of sysinstall is simply too busy to donate their hours. As you said... FreeBSD is primarily a volunteer project. > It's worth noting that the original > author of sysinstall considered it to be a temporary stop-gap until > something better was developed. Yes, this has been noted a thousand times over, it's in the man-page, it's been said on the lists, and does not need repeating. Yet, obviously time speaks for itself ... 15+ years of production use and still going ("temporary" or not, something must have been done right to win the respect of hardened C experts -- of which are directly responsible for extending its life for those 15+ years). Just look at the commit logs ... do you see the same disparaging overtones in the commit messages? no. Do you see the developers that are actively working on sysinstall bashing it like you do? no. On the contrary, the developers that _do_ maintain sysinstall are all constructive and productive members of the community. As an external observer's point of view... it's very easy to quote a one-liner that serves ones own desires ("but the author said..."). Lord help us if we were all held accountable to what we said 15+ years ago about our own products. The fact remains that even if the author said "this is a heaping pile of spraint", it doesn't change the fact that he developed something that was in-fact elegant regardless of whether the original author thought-so or not. By this same sentiment Einstein himself called the general theory of relativity a minor stepping stone and an incomplete view of the universal laws of physics (he died before he could marry the fundamentals of quantum mechanics with the same laws that govern large bodies in astrophysics -- dubbed in his time the [elusive] unified field theorem). Does that mean that the initial work was any less magnanimous? Pay homage to your roots and don't trash the people that maintain the products that got you where you are today. > The increasing disparity between > FreeBSD's features, together with the opaqueness of sysinstall have > led to a replacement being developed. Excellent. As I said before, I welcome our new bsdinstall overlords. I'm still undecided as to whether bsdinstall implements enough sysinstall features to be useful for us, and with that sentiment it is that we decide to put sysinstall on life-support until that can be answered (which could take months to answer, and if the answer is _no_, then we'll extend sysinstall's life-support even further until bsdinstall can be made to support the same featureset that sysinstall provides -- mostly speaking about scripting abilities here ... which includes much more than just simply pre-configuring the disk allocation metrics as you will see upon full-release of our automated install platform in coming weeks/months). So, I don't see why you must balk at this. We're going to spend a _LOT_ of voluntary time over the next coming years to enhance bsdinstall so that it is as feature-rich as sysinstall is when it comes to scriptability. > No-one is forcing you to > replace sysinstall on your legacy systems It's true that I brought FreeBSD-4.11 into the discussion, but everything discussed is in relation to RELENG_9. > but if you want sysinstall > to remain the default installer, you are going to need to add the > missing functionality to it. *sigh* I don't _need_ to do anything. The people in the enterprise circuit agree with our stance (you are thus far alone in thinking that sysinstall is utterly worthless unless it supports GPT, ZFS, geli, gmirror, and a host of other things). > > -- > Peter Jeremy -- Cheers, Devin Teske -> CONTACT INFORMATION <- Business Solutions Consultant II FIS - fisglobal.com 510-735-5650 Mobile 510-621-2038 Office 510-621-2020 Office Fax 909-477-4578 Home/Fax devin.teske_at_fisglobal.com -> LEGAL DISCLAIMER <- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. -> FUN STUFF <- -----BEGIN GEEK CODE BLOCK----- Version 3.12 GAT/CS/B/CC/E/IT/MC/M/MU/P/S/TW d+(++) s: a- C+++_at_$ UB++++$ P++++_at_$ L++++$ E- W+++ N? o? K? w_at_ O M++$ V- PS+>++ PE_at_ Y+ PGP-> t(+) 5? X(+) R(-) tv+ b+>++ DI+ D+(++) G++ e>++++ h r+++ z+++ ------END GEEK CODE BLOCK------ http://www.geekcode.com/ -> END TRANSMISSION <-Received on Wed Feb 23 2011 - 02:23:52 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:11 UTC