|
Grex > Coop12 > #94: Minutes March 21, 2002 Board Meeting | |
|
| Author |
Message |
| 25 new of 136 responses total. |
cross
|
|
response 100 of 136:
| 
Apr 26 20:16 UTC 2002 |
No, nothing to add, but I'd really subtract that ``vandal-resistance''
statement. I've given what I think are fairly complete answers why in
the garage group. Marcus' argument as I understand it is that things
like buffer overrun attacks, which are mostly scripted and mostly for
x86, won't work against SPARC (for the basic technical reason that a
SPARC processor is not an i386 processor. Ie, if you find some way to
do something bad to a Ford, it might not do anything against a Chevy
since a Ford is not a Chevy).
My arguments in return are that it's unlikely to matter for the following
reasons: (1) most network services can (and should) be pushed off onto
other machines where performance is not as much of an issue anyway, (2)
scripted attacks are unlikely to do much already since grex doesn't seem
to like to run much in the way of stock software, (3) grex has already
chosen to run software which fixes many of potential problems proactively,
and (4) SPARC is the second most common architecture for such things; the
time lag between when an x86 exploit comes out and when a SPARC exploit
comes out is negligable in most cases, and (5) those who can get around
the first 4 reasons aren't likely to be seriously hampered by the fact
that grex is running on a SPARC processor instead of an x86 processor,
as they'll likely have the technical skills to retarget their attack.
The other things Marcus lists I think are roughly the same between x86
and SPARC. x86 clearly has a massive lead over SPARC in the spare parts
category; I'd say the two are roughly the same in terms of reliability,
though x86 is getting better and SPARC is getting worse; x86 has a clear
advantage in terms of performance, especially at the price range grex
is talking about. x86 is a clear winner in both cost in availiablity,
as well. I'm guessing that Marcus is refering to the ease with which
one can open the thing up and muck with the insides when he mentions
servicability. Nice x86 hardware is just as good as SPARC here; in
particular, all you really need is a nice case.
In terms of power consumption, either choice will draw less current
than the current dinosaur that grex is running on; I'm guessing that
x86 would be the winner, but that's only a guess; everything else is
my own personal experience and/or common industry knowledge.
|
mdw
|
|
response 101 of 136:
|
Apr 28 06:39 UTC 2002 |
The main reason why resale value matters to us is that it determines the
price and availability of used equipment and spares. From our
perspective, a low resale value is very attractive, and the home windows
market is competition that pushes up our costs.
Serviceability is that which affects the ability to fix the machine once
it breaks, or to make upgrades. This includes factors such as hardware
construction, diagnostics, and error checking. Our past sun hardware
has been very well built, starting with the sun-2 which lived in a 1/8"
gauge metal box. Suns come with an interactive rom monitor - this makes
it possible to interact with the hardware, boot from alternate devices,
and run simple diagnostics even if the system is too sick to boot.
Error checking was once the cornerstone of the computing industry.
We're very far away from that with today's virtual parity windows
machines. Still, people who know and expect machines to run in
automated high performance/reliability situations generally still
specify ECC memory for good reason. Disk and I/O are other areas where
self-checking is important.
Vandal resistance is hard to quantify, and easy to overlook. Yet, most
public access systems, and even many for-pay systems founder on exactly
this point. Arbornet hit an early stumbling block with this--their
initial selection of a high performance 80186 based system, which was
probably fatal for its original commercial goals. Nyx changed its
mission statement radically as a result of overlooking this. With grex,
we have made vandal resistance one of our goals, from day #1, for both
hardware and software. I believe it is no exauguration to say that we
would not be having this discussion today if we had overlooked anything
in vandal resistance.
|
jmsaul
|
|
response 102 of 136:
|
Apr 28 15:09 UTC 2002 |
I think it probably *is* an exaggeration. Arbornet, as you point out, hasn't
emphasized vandal resistance the way you have, and is still around. You guys
have a lot more money. You wouldn't even have had as long a downtime as we
did.
|
gull
|
|
response 103 of 136:
|
Apr 28 22:03 UTC 2002 |
Re #101: You keep bringing up ECC memory as if it's some exotic thing
unheard of in x86 circles. Every x86 server at work came with ECC RAM as
standard equipment, and most of the workstations there can accept it as an
option. Most of the servers also have integrated health monitoring in the
form of fan speed, temperature, and voltage sensors; one even has redundant
hot-swappable power supplies. I think there's little reliability and
servicability differences between good x86 equipment and good SPARC
equipment.
If you're going to bring up desktop-class x86 equipment as an example, then
we need to compare to low-end Sun workstations, which often are felled by
bad capacitors or dead non-replacable NVRAM batteries.
|
jmsaul
|
|
response 104 of 136:
|
Apr 28 23:35 UTC 2002 |
As an outside observer, this really looks like a religious thing on Marcus'
part.
|
gull
|
|
response 105 of 136:
|
Apr 28 23:55 UTC 2002 |
Yeah...honestly, I think we can all stop having this conversation, because
the decision was already made a long time ago.
|
jep
|
|
response 106 of 136:
|
Apr 29 00:18 UTC 2002 |
I believe Marcus also represents the views of STeve. There are two
dedicated and smart guys if that's correct, who are dead set against
using 386 technology. I disagree with them, and favor using the
commonly available and cheap Intel hardware used by almost everyone
else in the world, but I also try to remember that I neither could do
the job they do, nor would want to.
|
jep
|
|
response 107 of 136:
|
Apr 29 00:19 UTC 2002 |
I guess you could say they're priests of their religious position, and
I'm a devout follower of the priests.
|
gull
|
|
response 108 of 136:
|
Apr 29 00:51 UTC 2002 |
I have no problem with Grex using SPARC hardware. But let's not pretend to
be discussing alternatives when the issue's already decided. It's
pointless.
|
jp2
|
|
response 109 of 136:
|
Apr 29 00:59 UTC 2002 |
This response has been erased.
|
keesan
|
|
response 110 of 136:
|
Apr 29 14:44 UTC 2002 |
I thought the whole point of grex was to have endless discussions from
which people could learn things, even after an issue is decided.
|
jmsaul
|
|
response 111 of 136:
|
Apr 29 15:56 UTC 2002 |
I don't think one side of this discussion is interested in learning anything
on the topic. It's like discussing abortion rights, except that in this case
only one side is entrenched.
|
remmers
|
|
response 112 of 136:
|
Apr 29 19:16 UTC 2002 |
I sense a degree of entrenchment on both sides, which I think
is regrettable, and I also don't see what purpose the
arguing serves at this stage. I really don't see things
as being "decided" -- Marcus and STeve have their preferences,
but they are only two out of several staff members and although
their opionions certainly carry weight, they don't hold veto
power over hardware decisions. The full staff should be
involved in the final determination.
What we really need is a volunteer to test out OpenBSD on an
x86 platform, so that we can make a truly informed judgement.
(We had such a volunteer, but he's really too busy right now.)
Since the x86 machine that I'm donating for testing purposes
is still in my possession, and since my semester is ending
and I'll have more time for Grex staffish stuff, I'm willing
to do an initial install of OpenBSD on it to get things
rolling, although I don't feel qualified to investigate
all of the issues involved. But maybe with advice...
I'll need the OpenBSD CD to get started.
|
jp2
|
|
response 113 of 136:
|
Apr 29 19:29 UTC 2002 |
This response has been erased.
|
remmers
|
|
response 114 of 136:
|
Apr 29 19:50 UTC 2002 |
Nah.
|
jp2
|
|
response 115 of 136:
|
Apr 30 03:08 UTC 2002 |
This response has been erased.
|
russ
|
|
response 116 of 136:
|
Apr 30 06:03 UTC 2002 |
Re #112: Can't you download the ISO image and burn your own?
|
remmers
|
|
response 117 of 136:
|
Apr 30 10:38 UTC 2002 |
The OpenBSD folks explicitly don't offer an ISO image online.
They want you to buy it. $40 I think.
|
malymi
|
|
response 118 of 136:
|
Apr 30 10:47 UTC 2002 |
technically, no. but you can download all you need.
cheapbytes has it for $5 + shipping.
|
cross
|
|
response 119 of 136:
|
Apr 30 22:30 UTC 2002 |
Well, if the descision's already been made, what is it? :-)
Marcus, you do seem to have this thing about willful denial of the
capabilities of x86 hardware. The fact of the matter is that you *can*
get x86 systems with ECC memory, as has been stated several times before,
and most disk controllers allow you to interogate them, run diagnostics,
boot from different disks and media, and so forth. Similarly with
network interfaces and so on.
I'd say that the interface is worse than Sun's PROM monitor, being
based around this cheesy block character-based menu motif and all, but
you probably get more functionality. I'd even put forth that nice x86
cases are easier and nicer to work on than Sun cases.
I'd also say that bargain used x86 hardware is *seriously* cheap compared
to comparable Sun hardware. Plus, with such a huge market for new
hardware, you generally don't need to buy used parts. Compare a used
SBus ethernet controller to a Intel Etherexpress Pro/100+ 100MB/s PCI
Ethernet controller. The former you have to get from where; USENET
or some reseller? Used or refurbished? And you have to pay shipping,
deal with latency of delivery, etc. The latter costs $30 at CompUSA,
and are usually in stock (I used to buy them at CompUSA at 34th St and
5th Ave for that much), and is a *good* controller. Certainly doesn't
drop as many packets as a Lance chip on an SBus card.
And besides, the most likely components to break are: Disks, power
supplies, and mainboards. I've rarely seen a PC mainboard go. In fact,
I've personally never experienced it (though I know others who have,
but usually they were infant mortalities). Power supplies can be picked
up easily, and go with about equal frequency in Sun's and PC's. Well,
it's harder to get a replacement Sun power supply, and again, it's more
expensive. The disks are the same anyway; SCSI disks are SCSI disks.
If you buy good one's from companies like Seagate or IBM, they usually
go for reasons not related to the computer they're hooked up to (like
heat death).
|
mdw
|
|
response 120 of 136:
|
May 1 01:22 UTC 2002 |
Heh - I have nothing against x86 hardware per se. I have a K6 system at
home, and a pentium laptop. At work, the same machine room that houses
the elderly RS/6K that receives my mail, also houses a bunch of newish
and expensive looking Dell Severs. So please don't tell me I don't know
the capabilities or costs.
|
cross
|
|
response 121 of 136:
|
May 1 19:42 UTC 2002 |
Well, your comments tend to indicate otherwise. Like your repeated
statements about ECC memory. Okay, we *all know* that grex needs ECC
memory; why is this still brought up in comparing x86 and SPARC hardware?
Same with SCSI controllers, ethernet, decent cases and power supplies,
etc, etc, etc.
|
mdw
|
|
response 122 of 136:
|
May 2 02:40 UTC 2002 |
Because it's one of those things that's standard on most SPARC servers,
but an extra-cost option in the x86 world.
|
spooked
|
|
response 123 of 136:
|
May 2 04:44 UTC 2002 |
I think the point, though, is that ECC is a cheap extra - and, x86
hardware isn't necessarily primarily targetted at the server market, but
in Grex's case would prove adequate.
|
gull
|
|
response 124 of 136:
|
May 2 14:02 UTC 2002 |
Re #122: Dell, at least, has it standard on all their server-class stuff
now. I'm not sure it matters if it's an "extra cost option" if the total
cost is still cheaper, too.
|