Item 94. Minutes March 21, 2002 Board Meeting Anne Perry (mooncat) Tue, Mar 26, 2002 (18:04). 73 lines, 97 responses. Starring, in order of appearance: (pre: 7 pm) Mooncat*, Mary*, Other*, Aruba*, STeve* (with a brief KRJ visit) and MDW*, (* indicates Board Member) 1. Gavel Banging: 7:17 pm 2. Chairman's Report: See #7 3. Treasurer's Report: In February we took in $493, Spent $433. Two new members (Thank you!) So far we have collected $363 in March Membership is at a low 84 paid, and concern is beginning to rear it’s ugly head. (please make it go away! ap) Discussion regarding how to get more paying members, including those long-time members who have thought about contributing but just haven’t quite done it, or have forgotten to renew their memberships, current plan- MOTD message. (which is currently up) Also, do we want to do something in appreciation of our members? Bank Account: Interest rate dropped from 1.74% (when Mark/Aruba opened the account) to 1.25% (as of 3/21). 4. Publicity Committee: Anne/Mooncat reported in for Bhelliom- re- opening Grex store in progress (getting prices, making item, etc.) to get rid of old items. New items? Do we want to find a way to get new shirts, perhaps with a new design? Could we maybe put Grex shirts up for sale in consignment shops around town(s). Much discussion, no conclusion at this point. 5. Technical Committee: “Marcus (MDW) has done wonderful things!” says STeve. MDW has loaded OpenBSD on one of the machines (mentioned in last month’s meeting minutes) and is running Solaris on the other. The BSD seems stable and useful for something, but there are some bits missing (like a debugger). Operating system isn’t quite doing what it should be. Gut feeling: too early to tell, target time a year from now. Need to come up with a series of ‘Metrics’ to see if the platforms will do what we want them to do. STeve and MDW will be putting together a list of ‘Things New Grex Platform MUST Be Able To Do’ and post it in the garage conf for discussion. Other than that, again it has been a rather quiet month. A few re-boots have been needed. 6. Schedule Next Meeting: Thursday, April 18, 2002 7:00 pm, Zingerman's Next Door. 7. Reporting Paperwork: Eric/Other spoke to his advisor (father) and the conclusion there was that we did need to send in the forms. This fit with the decsion the rest of the board had pretty much come to so there was agreement with this assessment. Forms have been sent in sans cover letter. 8. New Business: Art Fair; an anonymous source has contacted us with the idea of getting a booth at Art Fair. Talk followed regarding the ever popular Art-On-A-Stick and how Grex could capitalize on this (tangented over the method one would have to use to actually cut computer pieces apart without completely shattering it?), maybe we could sell T-shirts. Problem- Who would man the booth and who would take charge of organizing this? Auction- when do we want to do another? Decided to start the next auction in September (give people time to find items to donate and others time to save!) and Anne/Mooncat agreed to assist as an additional auctioneer. 9. Bang Gavel: 8:48 pm These are the events as I saw them. Please let me know if I’ve missed anything. 97 responses total. ---------- (94) #1 Joel N. Weber II (devnull) Tue, Mar 26, 2002 (18:38). 21 lines. How much has membership actually declined? Like, what's the high? How has it varied over time? It also seems to me that the things that really make grex work are: 1) The staff 2) The users, who make the interesting discussions happen 3) Having enough money to pay the bills Now, a declining number of members might mean that there's correspondingly a declining number of users, in which case, recruiting more users and having some of them happen to become members might be the right solution. A declining number of members might also make it harder to pay the bills, but my understanding is that grex's finances are quite solid at the moment, so this isn't an immediate concern. Do we have any meaningful statistics about how many users there have been over time? I think number of people contributing to the agora conference would be a more useful measure than the number of poeple running newuser, or the size of /etc/passwd. ---------- (94) #2 Mark A. Conger (aruba) Tue, Mar 26, 2002 (21:20). 14 lines. It is certainly not time to panic about the size of the membership. Here are some numbers for membership in each half-month since the beginning of 2000: 93 87 98 97 90 99 92 88 94 95 89 102 96 88 100 91 89 93 95 92 103 90 91 100 90 90 92 91 96 100 87 95 99 89 97 91 93 97 100 90 94 96 87 98 88 90 94 97 90 97 95 87 95 84 As you can see, membeship has been approximately constant for a long time, though there have been low points before. I like to see it above 95 though. ---------- (94) #3 Psycho Freak Goalie (ea) Tue, Mar 26, 2002 (23:38). 21 lines. As far as getting new T-shirts, has Grex considered a website such as CafePress.com? They let you design your own shirts, give you a website from which to sell them, print them on demand, and then give some amount of profit to the seller. This has a few advantages and a few disadvantages when compared to the traditional "Grex Store" Pro: Grex does not have to maintain inventory Designs can be changed at will Grex sets the sale price More than just T-Shirts No up-front costs Can ship around the nation, easily, with no work from local Grex volunteers Con: No on-hand inventory, makes it harder to distribute at gatherings (such as walks, TOP events, etc) Base prices are a little steep (they set base price, Grex sets sale price) Turn-around on each sale is about 3 weeks not sure how long it takes for payments to grex following orders will they be around in 3? 5? 10? years? ---------- (94) #4 Mark A. Conger (aruba) Tue, Mar 26, 2002 (23:57). 3 lines. Valerie has been advocating CafePress instead of buying a bunch of shirts like we did last time. I think you summarized the pros and cons pretty well. ---------- (94) #5 JP2 * GREX * AND YOU! (jp2) Wed, Mar 27, 2002 (10:32). 3 lines. Three weeks? Every rder I have ever placed with them I had in five days or less. Also, Grex can buy a mess, at the base price, and use that to give out at gatherings. ---------- (94) #6 Jan Wolter (janc) Wed, Mar 27, 2002 (20:46). 19 lines. Well interpretations of Marcus's findings on OpenBSD on the Sparc64 vary. I've always thought it was an absurd idea to try to run Grex on such an immature release, and Marcus's findings seem to me to be a solid demonstration of the fact. Grex needs to be running on proven, reliable software. OpenBSD/Sparc64 still has major functional holes. It's not only not proven, it's barely begun to be usable. The "we have a year" business is silly too. Yes, the last two machine upgrades took us a year each. At the time, I considered that cause for serious embarassment. Now all the sudden it's the baseline, and we don't even have to worry about the fact that Sparc64/OpenBSD doesn't work very well, because we're sure that someone somewhere must be more efficient than we are, and will actually get it fixed and totally up to production quality before we can install and configure it. Oh, well. Just wanted to register for people who don't read the staff conference that staff is not unanimous on this OpenBSD/Sparc64 stuff. Probably discussion belongs in the garage conference, not here. ---------- (94) #7 Psycho Freak Goalie (ea) Wed, Mar 27, 2002 (22:27). 2 lines. #5 - admittedly, I've only purchased from them once, and it was when they were still fairly new. ---------- (94) #8 C. S. McGee (cmcgee) Thu, Mar 28, 2002 (08:13). 2 lines. Thank you Jan. Normally I wouldn't look into the Garage conf, so I appreciate the other point of view. ---------- (94) #9 Jan Wolter (janc) Thu, Mar 28, 2002 (10:06). 2 lines. One correction to a typo in #6: There is no discussion of this in the 'staff' conference. It's all in the 'garage' conference. ---------- (94) #10 Dan Cross (cross) Thu, Mar 28, 2002 (12:13). 11 lines. Regarding #6; I agree with Jan 100%. OpenBSD on UltraSPARC just isn't there yet; it's likely it won't be there a year from now, either. AMD hardware running OpenBSD is there right now, has a much better price/ performance ratio, and is much better understood than Sun stuff. Sorry, but there it is. I'd personally like to see more than just STeve and MDW putting together a list of things ``the next grex must do,'' for two reasons: 1) it's good to have more than just two people's input on a system used by 30,000, and 2) STeve and mdw are the people pushing SPARC over AMD's x86 clones. I'm slightly concerned about their objectivity. Sorry guys, but there it is. ---------- (94) #11 Anne Perry (mooncat) Thu, Mar 28, 2002 (13:58). 4 lines. re #10- I probably should have made this more clear in the minutes, but my impression was that while STeve and Marcus would be coming up with a list they would also discuss it in the garage conference and get input from other people. ---------- (94) #12 Dan Cross (cross) Thu, Mar 28, 2002 (18:07). 2 lines. Regarding #11; That's great. btw- I want to be clear that I'm not in any way question either Marcus' or Steve's integrity. ---------- (94) #13 Marcus Watts (mdw) Thu, Mar 28, 2002 (22:33). 3 lines. It is possible for two perfectly logical people, starting with the same facts, and both exercising great judgement and objectivity, to reach completely opposite conclusions. ---------- (94) #14 Dan Cross (cross) Thu, Mar 28, 2002 (22:48). 9 lines. That's true in an abstract sense, but this is a technical argument, with a basis in mathematics and good engineering. Therefore, it's up to you to present a compelling engineering argument, which to date, I'm afraid you haven't done. So far, all we have is your assertion that SPARC is ``better,'' but not backed up with any hard data. And, your non-technical arguments have been, in my opinion, less than compelling. I believe the last one was something along the lines of, ``we don't want a really fast machine because too many people will use it.'' Perhaps I'm totally on the wrong page, but that was my interpretation. ---------- (94) #15 The Accidental Purist (other) Fri, Mar 29, 2002 (01:30). 2 lines. Nothing I have heard or read in discussion on this topic has been translatable to that. ---------- (94) #16 C. S. McGee (cmcgee) Fri, Mar 29, 2002 (09:01). 4 lines. Whether or not this argument has a basis in mathematics and good engineering, it sounds like there are policy implications as well. While I can follow most well reasoned engineering explanations, I also appreciate the non-technical opinion comments. Keep at it folks! *grin* ---------- (94) #17 David Brodbeck (gull) Fri, Mar 29, 2002 (10:11). 2 lines. One serious point in favor of SPARC, as I understand it, is that we've already been given a SPARC machine, but we'd have to buy an AMD clone. ---------- (94) #18 Michelangelo Giansiracusa (spooked) Fri, Mar 29, 2002 (10:58). 5 lines. I don't think this is true, gull. John Remmers is donating his x86 machine - not sure if it's Intel or AMD hardware exactly. And, in any case, AMD/x86 hardware is cheap,cheap,cheap and readily available - unlike SPARC. Notwithstanding this, I don't this the hardware per se is the problem - it's the stability of the port which is of concern. ---------- (94) #19 Dan Cross (cross) Fri, Mar 29, 2002 (15:08). 64 lines. I think it's both the hardware and the stability of the software. It seems logical that you want something that is fast, robust, cheap, and easily upgradable/fixable/replaceable. Cheap and available spare parts a must, with good software support. AMD-based x86 machines give you this, while Sun's just don't. They might in a year, but then again, they might not. Given the length of time it took to get the sun4m port stable, I don't have too much confidence. What's more, Sun's are slow (sorry, there it is; I've seen loads of empirical data to back up the assertion that Sun's are slow compared to AMD x86 machines), they're proprietary, replacement parts generally need to be ordered from somewhere and can cost a lot. Sun's are expensive. Brand new x86 server class machines can be bought for sub $1000, while Sun's low-low-low-end el-cheapo workstations cost about that, but aren't nearly as good. And software support for OpenBSD on UltraSPARC came into existance, what, a couple of months ago? OpenBSD on x86 has existed for years; it's really solid on AMD, and the quality reservations that have been voiced about Intel are mitigated by using a different vendor. The arguments I usually hear are that it's easier to have a stable and robust port on Ultra hardware because it's simpler. I disagree; x86 has a huge head start in this area, and it took the OpenBSD team *years* to get things stable on sun4m. Why should I believe that they can do better on sun4u? And, why did it take them so long to get sun4m support squared away in the first place? PC's where ``there'' a lot more quickly, despite being a more complex architecture. I hear that Sun's have higher quality hardware, to which I respond that they used to, but quality has gone way down in recent years. Look at machines like the Ultra 5 and 10, or the Blades; they're not built like the tanks that were the SPARCstation 1's and 10's. I hear that crackers are going to have less success mounting a pre-scripted attack against a Sun, because most attacks x86, to which I respond that script-based attacks are generally pretty easy to thwart. It's likely that grex won't be running many stock servers to be attacked, so will be mostly immune to script-based attacks anyway. Those attackers with the technical ability to overcome THAT limitation aren't likely to be daunted by a different architecture. The last argument I heard was about speed not being a factor. (Note: whoever wrote #15, I'm pulling this next part from #128 in the garage group). Marcus had this to say towards the end: It is common to think that performance problems are solved by finding the "fastest" solution. Well, sometimes that works. Sometimes it doesn't. It's a well-known traffic engineering conundrum that building bigger and better roads merely leads to more traffic, and ultimately, larger and even more desperate traffic jams. Marcus continues about general queueing principles, traffic loads, etc. There's some statements about changing mailers to something more efficient increasing mail load and thus increasing the network traffic load on the network link (which, to my knowledge no one has ever measured to see just how loaded it is, so it might not be loaded at all). I interpret his argument to mean that grex doesn't really want a faster machine because it'll be more susceptable to being loaded down, in which case the question is raised: why change machines at all? Oh, and about the issue of a Sun being available now, while an x86 machine is not, did not someone donate a large amount of cash to grex specifically for the purchase of a new computer? Okay, so *is* there a compelling reason for wanting to use SPARC hardware instead of x86? ---------- (94) #20 Sindi Keesan (keesan) Fri, Mar 29, 2002 (15:24). 5 lines. I think the donation was for 'hardware' in general, not a 'new' computer specifically. One of the reasons for using SPARC seems to be that the volunteers find it more interesting to work on something less common. If they are going to be putting in a lot of time, they want to learn something new. ---------- (94) #21 Dan Cross (cross) Fri, Mar 29, 2002 (15:31). 5 lines. Regarding #20; I think that if you took a survey of the volunteers putting in effort as grex's staff, you'll find that x86 would be new for them, while SPARC is old-hat. Consider that grex has been running on Sun hardware for it's entire lifetime. I gather from his comments that Marcus works with it every day. ---------- (94) #22 Jan Wolter (janc) Fri, Mar 29, 2002 (19:26). 13 lines. Re #17: First note that the person who donated the SPARC machines is Dan Cross, who is obviously not their biggest fan. Also note that the machines we have are not the ones we really want. I think people were talking about at least an UltraSparc 5. We have a 1 and a 2. Good enough for developing the software, but not very fast. John Remmers says he will be donating a Pentium machine for us to do similar development on an Intel platform. I think this was a 400 MHz machine. This also is slower than what we want, but it is going to be much faster than the UltraSparcs, I think. We can afford to buy a nice Gigahertz machine, especially if we procrastinate for a year. At any price level, be it free or a couple thousand dollars, we will get much more performance from an x86 machine. And this gap is only going to grow with time. ---------- (94) #23 JP2 * GREX * AND YOU! (jp2) Fri, Mar 29, 2002 (19:28). 1 line. True, but a nice PPC system running Linux, BSD, or Darwin will beat theAthlon. ---------- (94) #24 Jan Wolter (janc) Fri, Mar 29, 2002 (19:57). 2 lines. Last I saw, there were no PPC systems on the market that were appropriate to use as a server for Grex. I don't think it is a viable option. ---------- (94) #25 JP2 * GREX * AND YOU! (jp2) Fri, Mar 29, 2002 (19:59). 2 lines. I think some of the Mac systems may be viable, no? What features are they missing? ---------- (94) #26 David Brodbeck (gull) Fri, Mar 29, 2002 (20:15). 2 lines. The x86 architecture probably has a future. PPC may go the same way the Alpha did. PPC machines are also behind x86's in performance per $. ---------- (94) #27 Dan Cross (cross) Sat, Mar 30, 2002 (00:00). 1 line. Also, I don't believe that the Mac systems support ECC memory. ---------- (94) #28 Marcus Watts (mdw) Sat, Mar 30, 2002 (22:18). 46 lines. The PPC market is split - there's IBM, and then there's apple. There's also Motorola and a few speciality folks. IBM makes some very nice higher end stuff, which is only mildly overpriced. Apple has traditionally *never* included ECC or even parity. Every organization has its corporate blind spots. Apple apparently feels it's more important for something to keep running than to detect and report errors. (Contrast this with the original IBM PC which included parity in an era when personal computers *never* had parity, because they came from a background (banking/business) where errors are simply not acceptable.) Motorola and the speciality folks make machines for various market speciality market niches, such as engineering, embedded controllers of various sorts, & so forth. For a bit, it looked like IBM, Apple, & Motorola were coming together to make up a common motherboard standard. If this had come off, there might have been enough mixing of these various markets to make it possible for grex to purchase a low-cost motherboard with the appropriate features. Unfortunately, this never happened, which is regretable on many levels. Technical arguments, with their basis in engineering and mathematics, are even more prone to schisms based on original premises. Any engineer who can't admit this is so hopelessly tied up in his original premises that his judgement can no longer be relied upon, in any field. And, in fact, in the previous paragraph, it's easy to recognize different rational engineering decisions being made based upon fundamentally different initial premises. Pure science is no less immune to this disease of the initial premise. Most of the more important scientific discoveries are made by relatively young people, and often by people who aren't in the mainstream. It then generally takes about a generation for the discovery to become generally accepted, which is oddly enough the time it takes for the old establishment to die out. Sure, we want a fast machine, but we also want a *Consistent* machine. I've heard from various people, at various times, that PC hardware generally tends to behave more inconsistently and less pleasantly, under great load. What that would translate to in human terms, is a machine that is faster by any objective measure, but feels subjectively slower and is more annoying to use. Measuring pure speed is easy to do. Measuring *consistency*, load, & human factors is not nearly as easy. Also, lest people claim I'm immune to the intel argument, allow me to point out: I have intel hardware at home (well, actually that and AMD K6-2). STeve is still very proud of his pentium 4 based IBM laptop, with its 1600x1200 display and running OpenBSD. At work, I may be switching our mail server over from running on an IBM RS/6000 530H, to some newer intel based thing. Different hardware and software are best at different things; there is no one best answer for all things. ---------- (94) #29 Jeff Kaplan (kaplan) Sun, Mar 31, 2002 (07:59). 11 lines. It might help give this project a focus to pick a target end date. Haven't we been saying that we expect this project to take a year for several months now? I'm not saying that a volunteer effort like this needs a deadline. I'm just suggesting we should be able to pick an absolute target date rather than continuing to use a sliding relative time scale. On March 21, resp:0 says, "target time a year from now." I propose we take that statement literally and set a target of March 21, 2003. Hopefully the transition to new hardware will be completed much sooner, but can staff agree that a target of a next March is reasonable? ---------- (94) #30 Dan Cross (cross) Sun, Mar 31, 2002 (20:38). 7 lines. Regarding the initial premise thing, it strikes me that if I have a microcontroller running a safety critical pressure release valve, it damn well better detect and report errors. I've never heard this inconsistency argument before, and I've been running Unix on x86 hardware for many, many years. Perhaps you could be a little more specific? ---------- (94) #31 David Brodbeck (gull) Mon, Apr 1, 2002 (15:22). 8 lines. It's probably true that Sun hardware, with its more hardware-based multitasking, performs better under very heavy loads than Intel systems. Certainly, my subjective observations have been that a Sun system with a load average of 10 'feels' as fast as an Intel system with a load average of 3 or 4. But Intel hardware is so much cheaper than Sun hardware that you can simply purchase a powerful enough system that you never reach those kinds of load averages. I know a lot of people will take offense at that kind of "get a bigger hammer" approach to performance, but it works. ---------- (94) #32 Dan Cross (cross) Mon, Apr 1, 2002 (15:45). 16 lines. Really? I don't know; I find Sun's feel uniformally slower than x86 machines, even under really heavy load. The Sun I'm sitting in front of right now feels extremely slow, and the number of processes running on it isn't that great. Hardware multitasking is nice, but really no substitute for good context switching code. An empirical piece of evidence is Plan 9 running on x86 hardware compared to running on, say, SPARC. It's just not faster, no matter what kind of load is running on it. What we're really talking about is scalability. x86 hardware really does scale as well as other stuff these days, particularly at the level we're talking about here. Witness that the main Plan 9 CPU server at Bell Labs is a quad-processor Xeon machine. I can personally tell you that that machine (which replaced an 8-processor SGI Challenge XL machine) is hammered quite frequently, with both big compute jobs and lots of processes. The hardware context stuff just isn't needed, but Plan 9 is probably a lot more efficient than Unix at doing context switches. ---------- (94) #33 Steven R Weiss (srw) Wed, Apr 10, 2002 (00:54). 6 lines. Someone was saying that Grex's new x86 donated by Remmers at 400 Mhz is not fast. It isn't. Faster ones can be had cheaply though. 4 months ago, HVCN bought a brand-new 900 Mhz Celeron server from Dell for $528 (including 128M Ram and 20GB HD. We would clearly add Ram for Grex) This machine is in service, running OpenBSD 3.0 since 1/2/02. It's very nice. http://www.hvcn.org/ ---------- (94) #34 John H. Remmers (remmers) Wed, Apr 10, 2002 (09:39). 2 lines. Right. The intent isn't to use it as a production machine, but rather as a testbed for OpenBSD on x86 hardware. ---------- (94) #35 Blaise de Cormeilles (blaise) Wed, Apr 10, 2002 (14:18). 2 lines. I just bought a brand-new 950MHz Athlon server with 256M RAM and 20G drive for $370 (including shipping). ---------- (94) #36 Dan Cross (cross) Wed, Apr 10, 2002 (15:43). 3 lines. Wow, that's cheap. Grex will likely want SCSI, which adds a bit of cost, but only a few hundred dollars, and there's money in the bank specifically earmarked for hardware. ---------- (94) #37 Marcus Watts (mdw) Wed, Apr 10, 2002 (18:07). 2 lines. Something else we'll want to add too is ECC memory. Yup, consume grade equipment is very cheap, but there *are* things you sacrifice. ---------- (94) #38 Dan Cross (cross) Thu, Apr 11, 2002 (12:28). 3 lines. ECC memory is cheap. I've seen gigabytes of it for sale on the streets of New York for under $100. It's really not that hard to put together a PC that's a steal that still has the features you want. ---------- (94) #39 David Brodbeck (gull) Thu, Apr 11, 2002 (14:49). 2 lines. Most of Dell's servers now have ECC memory as an option. Heck, even their high-end desktop workstations do. ---------- (94) #40 Marcus Watts (mdw) Fri, Apr 12, 2002 (02:03). 2 lines. No wonder ECC memory is hard to get; it's only available from NYC street vendors. ---------- (94) #41 Dan Cross (cross) Fri, Apr 12, 2002 (11:18). 4 lines. Along with antiquated books on LISP systems, and movies on tape that came out in the theater the day before. Nevermind that the picture on the latter wobbles, and you can see all these funny shapes moving around towards the bottom of the screen.... ---------- (94) #42 Blaise de Cormeilles (blaise) Fri, Apr 12, 2002 (12:58). 1 line. ECC would have been $100 more on my new system. ---------- (94) #43 Jan Wolter (janc) Sat, Apr 13, 2002 (21:27). 10 lines. To clarify the purpose of John's system. In the past it has taken us about a year of work to port Grex to a new OS. So the idea is instead of buying the latest and greatest computer now, and having it a year old before we let people onto it, we use John's old system to port all our software, then buy a new computer, and do a quick install of all the stuff we worked out. Thus we end up with a better computer for our money. Of course, since nobody is working on doing the upgrade (so far as I know) it may take more than a year this time. ---------- (94) #44 Sindi Keesan (keesan) Sun, Apr 14, 2002 (10:20). 2 lines. But MDW is working on something to do with Dan Cross's donated computers? It sounds like whoever is willing to do the work gets to choose the system. ---------- (94) #45 John H. Remmers (remmers) Sun, Apr 14, 2002 (10:47). 1 line. That's not the way it should work. ---------- (94) #46 John Ellis Perry Jr. (jep) Sun, Apr 14, 2002 (11:41). 1 line. It's not? It sounds okay to me. ---------- (94) #47 John H. Remmers (remmers) Sun, Apr 14, 2002 (18:01). 10 lines. I guess it's reasonable if the result is something on which Grex can run satisfactorily. There's technical discussion of the platform issue somewhere in the Garage conference. Reservations have been voiced about the wisdom of running OpenBSD on a Sun Sparc platform, so I'm hopeful that somebody will volunteer to check it out on the X86 platform I'm donating. Had I been able to donate the machine a few months earlier than this, Jan would be working on it, but he's too busy right now. ---------- (94) #48 JP2 * GREX * AND YOU! (jp2) Sun, Apr 14, 2002 (21:16). 4 lines. I have voiced this before, and I will again here. On M-Net, we've ported extensive amounts of software to FreeBSD, and frankly, getting it from there to OBSD should be trivial. I cannot speak for the rest of M-Net, but any help I can offer is free. ---------- (94) #49 Dan Cross (cross) Sun, Apr 14, 2002 (21:25). 5 lines. Just because someone is volunteering to do it doesn't mean that's what should be done. I could volunteer to design a new space shuttle; NASA would be extremely unwise if they took my design and used it. There's something to be said for using the most appropriate tool for the job, not just the one that's the most fun. ---------- (94) #50 Sindi Keesan (keesan) Sun, Apr 14, 2002 (23:00). 4 lines. So who is volunteering to do what Jan is now too busy to do? Shall we wait until Arlo is old enough to set up a new system by himself? The most appropriate tool may be the one that there is someone willing to set up and maintain. Has anyone besides Marcus volunteered recently? ---------- (94) #51 Marcus Watts (mdw) Mon, Apr 15, 2002 (00:25). 3 lines. STeve Andre' said he wants to install obsd on remmer's old machine. Since he's already got obsd running on many similar machines, he's the logical choice. If he can't get to it for some reason, I'll do it. ---------- (94) #52 Sindi Keesan (keesan) Mon, Apr 15, 2002 (08:32). 3 lines. Has anyone yet found the time to work on the faster modem bank, or at least to do something about the flaky modem at 761-3000? (Switch it with one at the end of the queue). ---------- (94) #53 Dan Cross (cross) Mon, Apr 15, 2002 (12:18). 6 lines. Regarding #50; No, this is an engineering descision, not something based on someone's personal preference. All the evidence so far suggests that OpenBSD on AMD x86 hardware is the appropriate choice, not OpenBSD on UltraSPARC. Even Marcus' own recent statements in the garage group echo that sentiment. Perhaps you'd care to spend some time reading through the garage group to see where things stand? ---------- (94) #54 Marcus Watts (mdw) Mon, Apr 15, 2002 (21:01). 1 line. That's cross's interpretation of what I said, not my sentiments. ---------- (94) #55 Russ Cage (russ) Tue, Apr 16, 2002 (00:03). 7 lines. Speaking of faster modems, I've only identified one of the seven Grex modems which reliably runs sz at anything close to the speed you'd expect from a 14,400 BPS data rate. Most of them run at less than half that, yet all the modems are supposed to be the same. Seems pointless to upgrade the modems when the other problems go un-addressed. ---------- (94) #56 Dan Cross (cross) Tue, Apr 16, 2002 (12:07). 16 lines. Regarding #54; I quote from your most recent statements on the matter in the garage group: As things stand, I'd say that sparc64 openbsd is certainly stable enough to get real work done, and likely stable enough to run in production for a non-demanding job and accumulate 100+ day uptimes. There are some performance issues that might be needed for a sufficiently demanding job, as well as perhaps other unknowns. There are certainly still issues that need to be solved before grex could use this for the main login machine, with active hostile users on the "inside". Well, perhaps it's my interpretation, but it seems pretty clear that you're saying it's not up to snuff yet, what with the comments about non-demanding jobs and performance problems. However, feel free to correct me if I'm wrong and that's not what you meant. ---------- (94) #57 Sindi Keesan (keesan) Tue, Apr 16, 2002 (20:40). 1 line. Perhaps Marcus is implying that he is presently solving the issues? ---------- (94) #58 Marcus Watts (mdw) Tue, Apr 16, 2002 (21:08). 6 lines. No, I'm being quoted out of context. Someone asked me how I thought the Sun port stood *today*. The actual target we care about is 6 months - 1 year ahead, including both work we do on our end, work the openbsd folks do at their end, work the hardware makers put into their hardware, as well as whatever changes happen in the marketplace for new & used hardware. ---------- (94) #59 Dan Cross (cross) Thu, Apr 18, 2002 (15:36). 18 lines. Regarding #'s 57 and 58; I think that it would be foolish to assume that Marcus can fix the problems. Don't take that as a slight of Marcus' technical abilities, but rather as an indication of the size of the task. It took the OpenBSD team something like 6 years to get the 32-bit SPARC port to anywhere approaching production quality. It's likely it'll take them at least several years to do the same with 64-bit SPARC; no one individual is going to be able to ``solve'' these problems in six months or a year. Regarding Marcus' statement about the hardware vendors: what does that have to do with anything? Sun isn't really helping the BSD developers. It's going to take years to get the UltraSPARC port into production shape. Historical precedence dictates that you should look at the shape of the OpenBSD SPARC-64 port now as a (close) approximation of the state of the port in 6 months. Besides, why would you *want* to use an architecture that's obscure and has a dubious future? ---------- (94) #60 Marcus Watts (mdw) Fri, Apr 19, 2002 (23:10). 1 line. You mean like i386? ---------- (94) #61 David Brodbeck (gull) Sat, Apr 20, 2002 (22:53). 3 lines. One thing i386 has going for it is that lots of vendors produce the stuff. That means it's cheap and it'll be plentiful for a long time. With SPARC you're pretty much locked into buying from Sun. ---------- (94) #62 Marcus Watts (mdw) Mon, Apr 22, 2002 (00:20). 3 lines. Er, there *are* several other sparc suppliers... And the peripheral market should be opening up now that they're not using their own proprietary bus. ---------- (94) #63 Dan Cross (cross) Mon, Apr 22, 2002 (12:19). 7 lines. Marcus, please, don't let your personal opinion cloud your judgement. x86 may not be the nicest architecture in the world, but it's far from obscure, and it definately has a brighter future than SPARC. Also, while there may be more than one SPARC vendor, there's only one that really matters, kind of like how there was more than one Alpha vendor but only one really mattered. I'm really rather surprised that you'd say such things. ---------- (94) #64 David Brodbeck (gull) Mon, Apr 22, 2002 (16:48). 1 line. Or sort of like how there was (briefly) more than one Macintosh vendor... ---------- (94) #65 lose money (styles) Mon, Apr 22, 2002 (18:18). 1 line. hey, man, my starmax is still (not really) chugging along. ---------- (94) #66 JP2 * GREX * AND YOU! (jp2) Mon, Apr 22, 2002 (20:28). 2 lines. Dude, I had one of those Starmaxes for a year running NetBSD. A VERY fine piece of equipment. ---------- (94) #67 Marcus Watts (mdw) Mon, Apr 22, 2002 (20:50). 3 lines. Design-wise: i386 *is* obscure. It's far out of the mainstream of CPU design, and in many respects isn't far from the IBM 7094 of the early 60's. It also has a limited future, if the ia64 architecture takes off. ---------- (94) #68 Mark A. Conger (aruba) Mon, Apr 22, 2002 (23:18). 3 lines. I think it's fair to say that there will be lots of i386 hardware available for longer than Grex will be on the machine we're talking about moving to now. ---------- (94) #69 David Brodbeck (gull) Tue, Apr 23, 2002 (10:38). 4 lines. I'm coming to the realization that this debate is pointless because platform selection is a religious issue. You're never going to convince a member of the Cult of the Sun to consider the doctrine of the Intelites. ;) ---------- (94) #70 David Brodbeck (gull) Tue, Apr 23, 2002 (10:39). 2 lines. (Incidentally, a lot of people seem to be of the opinion that Intel has blown the ia64 design. It remains to be seen, of course.) ---------- (94) #71 Dan Cross (cross) Tue, Apr 23, 2002 (10:48). 13 lines. No, it's not obscure. Obtuse, definately, but obscure implies uncommon, and x86 is practically the most plentiful chip out there. When SGI bought MIPS, Ken Thompson bemoaned the fact that i386 was going to take over the world. Phil Winterbottom said to him, ``they won, we lost, deal with it.'' Words to live by. The x86 chip isn't a great design, but it's cheap, it's fast, it's reliable, and it's extremely well supported by software. SPARC is none of these things (well, perhaps reliable, but that doesn't matter if it's not supported). Of course, I suspect that grex will end up on a Sun anyway. Too bad. ---------- (94) #72 JP2 * GREX * AND YOU! (jp2) Tue, Apr 23, 2002 (11:48). 2 lines. Actually, the Z-80 is the most common chip out there followed VERY closely by the 68000. ---------- (94) #73 Dan Cross (cross) Tue, Apr 23, 2002 (12:26). 2 lines. Yeah yeah yeah. I meant for end-user computer systems, as opposed to embedded devices. btw- is Z80 really still more common than 68k? ---------- (94) #74 JP2 * GREX * AND YOU! (jp2) Tue, Apr 23, 2002 (12:40). 3 lines. Last I heard, and it was only six months ago. Recently, I opened an alarm system in a friend's apartment, which was installed a year ago and found a Z-80 inside it. The thing isEVERYWHERE. ---------- (94) #75 David Brodbeck (gull) Tue, Apr 23, 2002 (16:15). 2 lines. TI-8x series programmable calculators use Z-80s, too. The Nintendo Gameboy uses a modified version of the Z-80. ---------- (94) #76 Marcus Watts (mdw) Tue, Apr 23, 2002 (19:01). 5 lines. Obviously, i386 (and z80...) is everywhere. The *design* though is, well, unique and uncommon. 68k has at least learned about general register architecture from the ibm 360. Digging back through history, well, um, an interesting parallel is the ford model T -- it was also unique yet ubiquitous. ---------- (94) #77 lose money (styles) Wed, Apr 24, 2002 (02:47). 32 lines. #71: you really think SPARC isn't fast? the only thing SPARC isn't is cheap, and didn't someone actually offer to donate an Ultra-II or two for grex? Ultra-II's are pretty damn fast. SPARC is inherently "faster" than x86 architecture-wise. x86 manufacturers have to boost clock cycles through transistor compaction and high-throttle fsb speeds, whereas the intelligent designed of the SPARC architecture and even the mere abundance of temporary registers in SPARC allow for comparible speeds without making up for the latency of a complex instruction set combined with the throughput retardation courtesy of excess memory transfers. sure, you can accellerate bus speeds to make your excess memory transfers faster, but ultimately you are going to be putting the assembly programmers of the world through the pain of dealing with a shitty instruction set. IA-64 attempts to address the innate crapiness of x86, but the prices are outrageous (maybe it's all just several dozen grand for the test models right now, and they're going to ditch the project anyway? dunno...). because they recognize that you can only invest so much into transistor packing and and bus amphetaminization before physical limits are reached and they are left with the walls of crackheaded design that they themselves erected. give yourself a frame of 32 general purpose registers, and allow yourself a save instruction, and suddenly the cycles required to perform menial tasks are extraordinarily reduced, particularly with function calls. plus, with SPARC-V9, you have 64-bit arithmetic, so you don't have to worry about quad_t double register operation emulation with gcc, because a single add instruction can handle that in SPARC-V9. why go with x86? dunno...because there's so much hardware available for it? because it's cheap? sure (again, didn't someone offer to donate Ultra-II's?). i would just personally rather not a) perpetuate mainstream acceptance of piss-poor CPU architecture b) rely on such a system whose components, although cheaper, are are likely not going to withstand the test of time that the current grex has endured. /$.02 ---------- (94) #78 David Brodbeck (gull) Wed, Apr 24, 2002 (12:46). 6 lines. Re #77: Grex has a limited budget. While to you and to Marcus this may be a religious crusade, I like to look at it from a $ per performance standpoint. When you look at it that way, it's hard to beat i386. i386 server-class hardware is every bit as reliable as the Sun stuff, too. I've seen at least as many Sun workstations break down as I have Intel machines. Some Sun designs have contained parts that did not age well. ---------- (94) #79 Dan Cross (cross) Wed, Apr 24, 2002 (13:56). 10 lines. Regarding #78; Yes, that person who offered to donate an Ultra 2, and who did so, was me. It's much slower than the kind of x86 hardware you can get for the same money, though. Look, SPARC might be better than i386, but don't hold it up as some pinnacle of good design. Take a look at MIPS for something much nicer. In the meantime, do some benchmark comparisons. The x86 architecture might not scale as well, but (a) it's integer performance meets or beats comparable SPARC chips, and (b) it's high clock rate pushed it over SPARC in terms of performance. ---------- (94) #80 Sindi Keesan (keesan) Wed, Apr 24, 2002 (15:06). 2 lines. Dan, are you offering (in 79 first par) to donate x86 hardware which is superior to whatever Marcus is thinking of using? ---------- (94) #81 Dan Cross (cross) Wed, Apr 24, 2002 (15:43). 11 lines. Regarding #80; I donated the two Ultra SPARC workstations, with 768MB RAM between them, and over 20 GB of disk. I understand that another user is donating x86 hardware comparable to what I donated; I think that the several thousand dollars worth of equipment I already donated to grex is quite enough for right now, thank you very much. But that's an aside; the main issue that is that x86 hardware is simply the appropriate hardware to use for the ``main'' grex. SPARC hardware would be fine for satellite machines, but not the main host; I've given reasons why. Perhaps you can give us a well-reasoned engineering rationale for why using UltraSPARC hardware is the appropriate choice? ---------- (94) #82 JP2 * GREX * AND YOU! (jp2) Wed, Apr 24, 2002 (15:52). 1 line. Don't you know by now that Keesan cannot reason? ---------- (94) #83 Dan Cross (cross) Wed, Apr 24, 2002 (17:20). 8 lines. I don't know if she can or cannot reason, but I find it pretty insulting that I donate thousands of dollars worth of equipment to grex, and this individual thinks I should donate more. I mean, don't get me wrong, I feel good about giving things to what I consider a worthy cause, and I think that the debate around x86 vs. SPARC is both useful and interesting (and perhaps the other participants feel the same way), but really, I think it's in grex's best interest to strongly pursue x86 hardware, and I'm not in a position to provide it. Sorry. ---------- (94) #84 Sindi Keesan (keesan) Wed, Apr 24, 2002 (19:02). 4 lines. I was simply asking what you meant by the first paragraph - it looks like your SPARC equipment is free but the equivalent x86 would have to be purchased. I did not mean to insult anyone and I know nothing about the relative merits of the two types of equipment. ---------- (94) #85 Marcus Watts (mdw) Wed, Apr 24, 2002 (23:04). 16 lines. As a general rule, I think x86 hardware *does* retain its value better, precisely because it can continue to run MS windows in people's homes years after the equivalent scientific/research hardware would normally be replaced by something newer and the older hardware junked. I should state that for the record, *I* certainly appreciate Dan's generosity, and I feel it will benefit grex, one way or another. The hardware he donated is indeed not suitable to be the replacement grex, but will very likely be helpful for producing future grex software offline, or may turn into a future satellite server. It's certainly already been directly useful to the openbsd folks; I found and reported several bugs, some with fixes, that they might not have found nearly so fast otherwise. Even if we go strictly with i386 in the end, this hardware will still be of benefit - a lot of OpenBSD is the same no matter what the hardware platform, so the effort we sink into higher level software is going to be very transportable between platforms. ---------- (94) #86 Mark A. Conger (aruba) Wed, Apr 24, 2002 (23:05). 1 line. Dan, we certainly appreciate your donation. It was very generous of you. ---------- (94) #87 JP2 * GREX * AND YOU! (jp2) Thu, Apr 25, 2002 (00:01). 1 line. If nothing else, sell the SPARC on eBay and use to proceeds to pay for x86. ---------- (94) #88 David Brodbeck (gull) Thu, Apr 25, 2002 (10:34). 9 lines. Re #84: Actually, my understanding is that the Sun hardware we've had donated isn't considered suitable for running Grex, so no matter which direction we go we'll be buying hardware. For the record, I think either solution can be made to work. I think this discussion is mostly about the "best" choice. I won't be terribly upset if the new Grex ends up on Sun hardware, I just think there's a lot of disinformation and FUD going around about i386 machines, and that bothers me. ---------- (94) #89 Mark A. Conger (aruba) Thu, Apr 25, 2002 (11:07). 2 lines. My major concern is that we pick the path which makes it easier to find new people to work on the system. ---------- (94) #90 Dan Cross (cross) Thu, Apr 25, 2002 (12:05). 11 lines. Thanks Marcus and Mark. I think that grex is a great thing, and am glad to be able to help support it in any way. Regarding #89; from the perspective of 99% of administration tasks, which don't involve the hardware as anything other than the black box that the software runs on, the hardware platform is pretty much immaterial. SPARC or x86 is only going to make a difference in that regard in a very small percentage of cases; in particular, only when the computer hardware itself needs to be fiddled with, which I gather is very, very rarely. Disks and things are another issue, but those are more or less the same regardless of wether the CPU is a SPARC or AMD i386 clone. ---------- (94) #91 Mark A. Conger (aruba) Thu, Apr 25, 2002 (12:10). 1 line. That's good to know. ---------- (94) #92 Mary Remmers (mary) Thu, Apr 25, 2002 (14:11). 1 line. I agree with Mark's #89. ---------- (94) #93 David Brodbeck (gull) Thu, Apr 25, 2002 (16:56). 4 lines. I agree with #90. Administering OpenBSD on a SPARC isn't really any different than administering it on an i386. When I tried it, the installation went a little differently, but once the system was installed there wasn't much of any noticable difference. ---------- (94) #94 Mark A. Conger (aruba) Thu, Apr 25, 2002 (17:07). 4 lines. Well, certainly a big part of Grex is installation - look how long the staff expects installation to take this time. So if being on one type of hardware or the other would make a difference in how quickly and easily we could move to the next machine, that's a consideration. ---------- (94) #95 Dan Cross (cross) Thu, Apr 25, 2002 (18:14). 7 lines. There's installation, and then there's Installation. The installation of the operating system on the bare hardware is a couple of hours work, maximum. The installation of all the software, services, configuration of those services, etc is that Installation that takes a *long* time, but that's independent of hardware once again. About the only part of the actually system installation that takes a while is figuring out how to partition the disks, but that is also independent of the hardware. ---------- (94) #96 Mark A. Conger (aruba) Thu, Apr 25, 2002 (21:40). 1 line. Hmmm. Well, what things *will* be affected by our choice of hardware? ---------- (94) #97 Marcus Watts (mdw) Thu, Apr 25, 2002 (23:28). 4 lines. Performance. Reliability. Serviceability. Vandal-resistance. Spare parts. Cost. Availability. Resale value. Some of these are easy to quantify. Some of them are much more fuzzy.