|
|
| Author |
Message |
| 25 new of 175 responses total. |
valerie
|
|
response 100 of 175:
| 
Dec 7 20:50 UTC 1998 |
This response has been erased.
|
janc
|
|
response 101 of 175:
|
Dec 7 21:31 UTC 1998 |
Is there a webvote program for this?
|
remmers
|
|
response 102 of 175:
|
Dec 8 01:31 UTC 1998 |
The closing date is Dec. 16 on the proposal (one day after the closing
date on the Board election). I mentioned it in the motd announcement
but neglected to here.
No webvote on this one. Promise to have that done for the next proposal
vote, whenever that may be.
|
davel
|
|
response 103 of 175:
|
Dec 8 04:10 UTC 1998 |
Hmmm. I could make a motion that ...
|
remmers
|
|
response 104 of 175:
|
Dec 8 08:25 UTC 1998 |
Please! No more motions until my semester is over. :)
|
aruba
|
|
response 105 of 175:
|
Dec 12 03:12 UTC 1998 |
I have finally gotten around to entering some new items in the auction! I
have about 100 descriptions of items typed in and organized, and I plan to
enter about 4 items per day in the conference for the next few weeks. If you
are looking for Christmas or Hanukah presents, and want to help out Grex in
the process, join the auction conference!
|
tpryan
|
|
response 106 of 175:
|
Dec 12 18:11 UTC 1998 |
Seems by the rules of the auction, today's new items could only
close in two weeks, on Dec 25th---what, one week minimun before auctioneers
start to close item?
|
aruba
|
|
response 107 of 175:
|
Dec 12 18:37 UTC 1998 |
The rules of the auction are that an item is "going once" a week after the
last bid, "going twice" a day after that, and "sold" a day after that.
|
tpryan
|
|
response 108 of 175:
|
Dec 13 18:56 UTC 1998 |
Close enough. IF today's bids get no other bids, the quickest
they can close is Dec 22nd. That's if the (auction) collective stays
on top of it. Payment/delivery could happen on Dec 23rd or 24th, but
the chance of that is slim.
|
aruba
|
|
response 109 of 175:
|
Dec 13 21:59 UTC 1998 |
Well, we con only do our best. It would have been better if I had been ready
earlier, of course, but I wasn't.
|
keesan
|
|
response 110 of 175:
|
Dec 14 01:04 UTC 1998 |
I cannot imagine anyone doing a better job on auction than Aruba, who also
has his own life to lead.
|
jep
|
|
response 111 of 175:
|
Dec 14 14:33 UTC 1998 |
I can imagine a better job, but I certainly couldn't do a better job. I
think Mark is doing well. If you want to give a Grex auction item as a
Christmas gift, arrange for a gift certificate. Or give late. Or just
buy it for yourself.
|
remmers
|
|
response 112 of 175:
|
Dec 14 15:53 UTC 1998 |
REMINDER: Tuesday, Dec. 15 is the LAST DAY TO VOTE in the Grex Board
of Directors election. The polls close at midnight (EST) on the end
of that day.
To vote or just to get information on the election, run the command
vote -from a Unix shell prompt
!vote -from a bbs or menu prompt
or on the web go to the URL
http://cyberspace.org/cgi-bin/pw/voting-booth
|
aruba
|
|
response 113 of 175:
|
Dec 14 16:51 UTC 1998 |
Re #110,111: Thanks for the support, Sindi and John. Tim (tpryan) is largely
responsible for this being the biggest Grex auction to date, because he
donated a whole lot of stuff, including about 100 books. I understand your
being frustrated, Tim, that it has taken so long to see some of your donations
doing some good, but it is, finally, happening.
join auction everybody!
|
other
|
|
response 114 of 175:
|
Dec 15 03:10 UTC 1998 |
10:04pm up 15 days, 8:54, 71 users, load average: 71.03, 63.52, 41.98
10:10pm up 15 days, 9 hrs, 77 users, load average: 71.22, 69.22, 54.47
???
|
steve
|
|
response 115 of 175:
|
Dec 15 11:59 UTC 1998 |
We were graced with a self-replicating life form last night.
(a fork bomb) ;-)
|
gregb
|
|
response 116 of 175:
|
Dec 15 13:53 UTC 1998 |
What is a "fork bomb?"
|
steve
|
|
response 117 of 175:
|
Dec 15 14:27 UTC 1998 |
A fork bomb is a program that makes infinite copies of itself.
It's "children" then start running and start spawning copies of
themselves, and before long (like less than a minute) most machines
will become completely preoccupied with running the fork bomb and
nothing else gets done.
Grex is in a little better shape. When someone runs a fork bomb
here, they can't use up all the resources, so Grex doesn't die--it
just becomes disgustingly slow, but things can still be done.
|
rcurl
|
|
response 118 of 175:
|
Dec 15 15:32 UTC 1998 |
Is the bomb run in just one directory or, if not, is it disseminated
among many? (That is, if telling won't compromise the system.....)
|
mjb
|
|
response 119 of 175:
|
Dec 15 16:51 UTC 1998 |
Um, not sure what you mean by that exactly. A fork bomb is a trivially
simple C program, (no, I'm not going to post one here) that is initiated
by a single user, and just starts filling process slots. The idea is
that it's a program that makes copies of itself. Consider the implication.
If it's a program that makes copies of itself, what do the copies do? Well,
they makes copies of themselves. On a system that has no safeguards in
place, it will bring a system to it's knees in short order. I'm not root
here, so I don't know what safeguards steve implied in #117, but I'd guess
it would be something to do with limiting how many processes a user can
have running. If this is unlimited (as it is by default on many systems)
then a fork bomb is devastating, and usually a reboot at the console is
your only recourse. If you limit the number of processes a user can have,
then the fork bomb will replicate till it fills the process space allocated
to the user (perhaps 16 or 32 processes) and then those will eat CPU, but
not enough of the CPU will be consumed to render the system useless. That
way, a root-type can still login, kill all the fork bombs, and get the system
back to normal. It's interesting to note that many kernels (like BSD that
m-net runs) there is one process slot reserved for root. That means that
when the system is topped out, root keeps one process in it's back pocket.
Of course, if a root person can't even 'su' to root cause he can't get a
process slot allocated, then that extra process doesn't do much good. ;-)
|
rcurl
|
|
response 120 of 175:
|
Dec 15 16:55 UTC 1998 |
You answered my question - the processes all belong to one user so the
codes are all in one directory. What is the limit on processes one
user can have at one time?
|
steve
|
|
response 121 of 175:
|
Dec 15 16:59 UTC 1998 |
People write them in their own directories or in /tmp, compile
them and then run 'em. It's a trivial, trival thing to write, so
simple that even the dullest vandal can simply type it in rather
than FTP it.
|
mcnally
|
|
response 122 of 175:
|
Dec 15 18:19 UTC 1998 |
I think #118, #120 probably indicate that Rane's confused by some of
the usage used in other recent responses.. There's no *file* copying
going on in a runaway fork program. There's just one copy of the
program in the filespace which gets run over and over and over. It's
the copying in *memory* (to hold multiple simultaneous invocations of
the same program) that's so resource-consuming.
|
gregb
|
|
response 123 of 175:
|
Dec 15 18:40 UTC 1998 |
How do you know--if there is a way to know--how many process to allocate a
user?
|
steve
|
|
response 124 of 175:
|
Dec 15 19:18 UTC 1998 |
I'm not sure I understand your question, but you can use the ps program
to see how many proceses are owned by whom, which is one way to spot
strange activity.
|
