|
Grex > Coop12 > #46: November 3rd, 6:00 PM, 607 Ross St.: Special meeting to discuss the future configuration of Grex |  |
|
| Author |
Message |
| 25 new of 181 responses total. |
mdw
|
|
response 157 of 181:
| 
Nov 6 00:10 UTC 2001 |
Part of the "too slow" was indeed network bandwidth -- not just telnet
sessions, but mail used by those people &etc. I wasn't too keen on the
queuing telnetd either, but at the time it was definitely was less bad
than some of the other fixes that were being suggested, such as turning
newuser off.
|
janc
|
|
response 158 of 181:
|
Nov 6 00:52 UTC 2001 |
Minor clarification: Grex has limited the number of users who can log in
simultaneously for a long time. The telnet queue is much more recent. It
used to be that people would just "attack telnet" until they got through, with
the most agressive people being the ones that got in first. Denying all those
telnet requests was becoming a load problem on its own. The queue was added
in to create a fairer and less resource intensive method for allocating
limited telnet sessions.
Presumably Marcus is talking about alternatives that were considered when Grex
first went on the net, which is before my line. I've never heard any serious
discussion of shutting off newuser.
|
goose
|
|
response 159 of 181:
|
Nov 6 03:47 UTC 2001 |
There were a couple of PDP/11s at Property Disposition...maybe danr sould have
picked those up too?
|
keesan
|
|
response 160 of 181:
|
Nov 6 16:10 UTC 2001 |
Jim says PDP/11s are washing machines. Probably has belts, big motors....
|
remmers
|
|
response 161 of 181:
|
Nov 6 16:31 UTC 2001 |
The real ones are, yes. But the virtual PDP/11s are really, really
tiny...
|
keesan
|
|
response 162 of 181:
|
Nov 6 16:32 UTC 2001 |
Jim: they don't take up any space at all as a matter of fact, a few million
or billion electrons.
|
steve
|
|
response 163 of 181:
|
Nov 8 05:43 UTC 2001 |
To be fair to the ultra OpenBSD port, it wasn't going to be included in
3.0 CD's originally, but it's been stable enough on several of the developer's
machines that it was deemed good enough to ship out. That says something to
me--the OpenBSD folks aren't willing to let something go out on the CD if
they don't have a lot of confidence in it. For at least two releases the
Alpha port wasn't included on the CD, because they didn't feel it was up to
par. I'm happy that it's made the light of day, but you'd better believe
that we're going to pound the hell out of it before we put real users on it.
There is software that needs to be added to the port, such as video drivers,
but thats an X issue--we can and likely will boot off the serial console.
What we need are SCSI and network drivers, which are already in the port.
For our use, I think the port is complete. There are two problems, amd and
rpc.statd that are known, but we aren't going to be using those, I don't
think. Amd is the automatic mount damon which isn't fixed, but rpc.statd
got fixed post 3.0.
True, OpenBSD doesn't yet support SMP. Thats going to be a while still.
I know there is work being done in that area, but I don't know where it is
at the moment. I'm not concerned about that now.
Lastly, to say it's an immature port really isn't quite right: its more
of a "young" port--it came to life in Janurary of 1999 on NetBSD and did a
lot of growth there, then was ported/integrated into OpenBSD late this
summer. So yes, it doesn't have the maturity of the i386 port, but then
again it shares a fair amount of code with the sun4 port, which works quite
well. If I didn't have a lot of confidence in this I wouldn't have suggested
this, but at the same time we're going to be looking at an i386 platform as
well. If the sparc64 port bombs out, we'll go with the i386. While I would
rather deal with sparc stuff, if it won't work out I would far prefer to see
us on i386 than deal with an unstable platform.
|
janc
|
|
response 164 of 181:
|
Nov 8 06:00 UTC 2001 |
I suppose one could just ask the people doing the port what they think. I
think there is a gap between "good enough to ship" and "good enough for the
heavily used primary server for an organization demanding high levels of
stability and security."
|
steve
|
|
response 165 of 181:
|
Nov 8 14:03 UTC 2001 |
They'd say "TEST IT!". And then flame us for asking such a question.
We're going to be a critical part of the success of the sparc64 port
working for us. It's up to us to test it and feel comfortable with it.
I don't mind this, because I'd want to test anything that we're
going to use. Pound the daylights out of it and be as mean to it
as possible.
|
janc
|
|
response 166 of 181:
|
Nov 8 17:06 UTC 2001 |
Hmmm. If someone asked me how ready Backtalk is for a heavy duty production
site, I'd be much more polite than that. As the person who best knows the
internals of the system, I can tell people things that they won't find out
by testing. (EG - I'd trust the current stable release a lot. The last
development release is mostly solid but has some minor glitches. The next
development release is going to be so radically revised that it should be
approached only by the courageous.) Ultimately I think they'd have to
try it out themselves, but I could sure give them a start. However, the
OpenBSD guys are a malcontent splinter group of a malcontent splinter group,
so maybe one should quake in terror before their wrath.
|
steve
|
|
response 167 of 181:
|
Nov 8 20:23 UTC 2001 |
Perhaps I am over-reacting to some of the past flamage on the OpenBSD
lists, but I don't think we'll get much in the way of advance help. It is
definitely the case that the OpenBSD crowd as a whole does not suffer fools
gladly, and people who ask inept questions or submit bug reports without
proper documentation are noisly roasted over a pit fire that has the words
CLUELESS over it.
I don't appreciate this aspect of the OpenBSD culture. It is however one
of amazing competance, such that software can spring up almost out of nowhere,
and be very very good. Around the time of OpenBSD 2.9 coming out, licensing
issues came out with regards the IPF packet filter program. It is apparently
not quite the open source model BSD style of license that people thought it
was, and it was dropped from the -current tree in June. In its place is pf,
the OpenBSD packet filter, which has gone from concept that different people
were working on, to a project of about 10 or so developers, which has matured
incredibly rapidly. It's on the 3.0 CD, and is already pretty solid. This
isn't to say that there aren't bugs in it--there likely are, somewhere. But
remember in the whole course of OpenBSD's using IPF, there were several
security updates regarding it, so am emergency update of pf wouldn't be
something really surprising. I will bet that fewer such security updates
will occur for pf however.
|
cross
|
|
response 168 of 181:
|
Nov 9 00:44 UTC 2001 |
It reamins that introducing support for a new architecture into an
operating system, no matter how well structured and how competent the
developers, is a hazardous task. Caveat emptor.
Also, there seems to be some confusion regarding hardware; if you
really want to use SBus cards, you can use newer model Ultras, since
they've migrated to PCI, and vice versa.
|
tsty
|
|
response 169 of 181:
|
Nov 9 07:49 UTC 2001 |
if the cream floats to the top in the openbsd culture, adn mdw/STeve&company
are there .... farm out! grex advances!
|
steve
|
|
response 170 of 181:
|
Nov 9 21:07 UTC 2001 |
Well, yes you're right Dan. That's why we're going to pound on it
a LOT, before we consider putting it in a production environment.
|
cross
|
|
response 171 of 181:
|
Nov 9 21:47 UTC 2001 |
Okay. I just want to make sure that the other folks who are following
the developments surrounding the next machine are aware of the issues.
|
steve
|
|
response 172 of 181:
|
Nov 9 21:52 UTC 2001 |
Right, and completely fair. We'll be *mean* to it.
|
cross
|
|
response 173 of 181:
|
Nov 9 21:57 UTC 2001 |
Hehe. Now, that's actually an amusing mental image. Somewhat like
a drill instructor yelling at a computer or something.
|
mdw
|
|
response 174 of 181:
|
Nov 9 22:01 UTC 2001 |
Everyone on staff wants a machine taht's rock solid, and I think this
was also pretty high on everyone's priority list.
|
other
|
|
response 175 of 181:
|
Nov 10 19:07 UTC 2001 |
Besides, STeve really needs the opportunity to be really mean to
something with impunity just to relieve the collected annoyance the
vandals and would-be vandals heap on him.
|
steve
|
|
response 176 of 181:
|
Nov 10 23:59 UTC 2001 |
Heh... thats true. Way back several centuries ago in the 1980's
I tested CCP/M systems and kept on finding bugs such that a project
that was supposed to be a couple of weeks turned into a five month
project. I promise to be mean to both implementations of OpenBSD,
but will cast more of a juandiced eye towards the sparc64 port.
|
keesan
|
|
response 177 of 181:
|
Nov 11 02:27 UTC 2001 |
Which juandiced eye do you plan to cast, the one with the patch?
(I hope progress is continuing to be steady.)
|
steve
|
|
response 178 of 181:
|
Nov 11 03:08 UTC 2001 |
hahahahahahahaha Excellent point! I'll cast a glare at it by
opening my eye patch and using the right eye. It will be both
the wrong eye, and the right eye, which of course makes be
juandiced. ;-)
|
keesan
|
|
response 179 of 181:
|
Nov 11 12:52 UTC 2001 |
Psst. The spelling is actually jaundiced, not juan as in Don Juan - I thought
this was an intentionally funny misspelling on your part.
|
goose
|
|
response 180 of 181:
|
Nov 11 23:10 UTC 2001 |
But STeve *is* DonJuandiced! ;-)
(heh...I don't even know what that means...)
|
orinoco
|
|
response 181 of 181:
|
Nov 13 19:07 UTC 2001 |
A donJuandiced eye would be a lustful and flirtatious one, presumably --
midway between beer goggles, and the come-hither look. I can't say I
reccomend that STeve cast that sort of glance at our software, but what
consenting developers do in their free time is their own business. ;)
|