|
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. |
remmers
|
|
response 150 of 181:
| 
Nov 5 15:30 UTC 2001 |
Hm. The Ford Motor Company once paid me pretty good money to
program in TOPS20 assembler some years back. If Grex decides
to go that route, I suppose I could refresh my skills. I'm
not holding my breath, though. :)
|
cross
|
|
response 151 of 181:
|
Nov 5 20:12 UTC 2001 |
Regarding #148; Well, TOPS-10 is a very different beast from TOPS-20.
Most of the emulators aren't quite there yet for doing newer versions
of TOPS-20 (newer here is obviously relative), since a KL processor
is required. TOPS-10 up through nearly the last release seems to work.
I suppose getting OS/390 would be difficult, since it's a pricey item
(and it's called z/OS now), but would be interesting. VM/370 running
on Hercules would be kind of neat.
I actually really like the idea of everyone logging into their own
emulated PDP-11 running 7th Edition; probably the last real version of
Unix ever made. You might run into some porting difficulties, though....
There's also RSTS if you go that route.
|
gull
|
|
response 152 of 181:
|
Nov 5 21:38 UTC 2001 |
Re #129: The telnet queue exists to limit network bandwidth use
(crudely), not processor load, I think.
|
cross
|
|
response 153 of 181:
|
Nov 5 23:24 UTC 2001 |
Regarding #152; I thought it existed due to a shortage of available
PTY's. Has anyone ever actually *measured* network utilitization?
It'd be silly to invest effort in limiting it if it wasn't a limiting
factor.
|
mcnally
|
|
response 154 of 181:
|
Nov 5 23:36 UTC 2001 |
ptys can be increased with nothing more than a kernel rebuild and a
MAKEDEV, so I doubt the reason was an actual pty shortage.
|
cross
|
|
response 155 of 181:
|
Nov 5 23:52 UTC 2001 |
Regarding #154; According to the grex staff pages, it was done because
the system got too slow when too many people logged in at once. Seems
like that problem goes away with a better computer. Without actually
measuring the utilization of the network link, I think it's a mistake
to say that the queuing telnetd `solves' any problem related to network
over-utilization.
|
scott
|
|
response 156 of 181:
|
Nov 6 00:07 UTC 2001 |
The current limit was set to reduce loads on both the CPU and also the network
link. Note that this isn't some value set way back on old hardware; it's the
one staff settled on with the current setup.
|
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.
|