Re: vm_zeropage priority problems.
On Sat, Dec 22, 2001 at 06:48:26PM +1100, Bruce Evans wrote: On Fri, 21 Dec 2001, Luigi Rizzo wrote: ... This would help removing the ugly property that priority-based have, which is that one process can starve the rest of the system. Only broken priority-based schedulers have that property. One of my incomplete fixes uses weights: which makes it weight based, doesn't it :) Most of the changes here are to fix style bugs. In the NEW_SCHED case, the relative weights for each priority are determined by the niceweights[] table. kg-kg_estcpu is limited only by INT_MAX and priorities are assigned according to relative values of kg-kg_estcpu (code for this is not shown). i guess the latter is the hard part... what kind of complexity does it have ? The nice feature of the scheduling code used in dummynet/Wf2Q+ is that it has O(log N) complexity where N is the number of active flows (processes in this case) and the basic scheduling operation is just one or two heap insert/delete, so it's really fast. cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: vm_zeropage priority problems.
Apparently, On Sat, Dec 22, 2001 at 06:48:26PM +1100,
Bruce Evans said words to the effect of;
On Fri, 21 Dec 2001, Luigi Rizzo wrote:
Don't know how interesting this can be, but i am writing
(no plans to commit it, unless people find it interesting)
some code to implement a weight-based instead of priority-based
scheduler. The code is basically the WF2Q+ scheme which is
already part of dummynet, adapted to processes.
It is quite compact, and i think i can make it reasonably
compatible with the old scheme, i.e. a sysctl var can be
used to switch between one and the other with reasonably
little overhead.
This would help removing the ugly property that priority-based
have, which is that one process can starve the rest of the system.
Only broken priority-based schedulers have that property. One of
my incomplete fixes uses weights:
Index: kern_synch.c
===
RCS file: /home/ncvs/src/sys/kern/kern_synch.c,v
retrieving revision 1.167
diff -u -2 -r1.167 kern_synch.c
--- kern_synch.c 18 Dec 2001 00:27:17 - 1.167
+++ kern_synch.c 19 Dec 2001 16:01:26 -
@@ -936,18 +1058,18 @@
struct thread *td;
{
- struct kse *ke = td-td_kse;
- struct ksegrp *kg = td-td_ksegrp;
+ struct ksegrp *kg;
- if (td) {
- ke-ke_cpticks++;
- kg-kg_estcpu = ESTCPULIM(kg-kg_estcpu + 1);
- if ((kg-kg_estcpu % INVERSE_ESTCPU_WEIGHT) == 0) {
- resetpriority(td-td_ksegrp);
- if (kg-kg_pri.pri_level = PUSER)
- kg-kg_pri.pri_level = kg-kg_pri.pri_user;
- }
- } else {
+ if (td == NULL)
panic(schedclock);
- }
+ td-td_kse-ke_cpticks++;
+ kg = td-td_ksegrp;
+#ifdef NEW_SCHED
+ kg-kg_estcpu += niceweights[kg-kg_nice - PRIO_MIN];
+#else
+ kg-kg_estcpu++;
+#endif
+ resetpriority(kg);
+ if (kg-kg_pri.pri_level = PUSER)
+ kg-kg_pri.pri_level = kg-kg_pri.pri_user;
}
I'm curious why you removed the ESTCPULIM and INVERSE_ESTCPU_WEIGHT
calculations even in the OLD_SCHED case. Do these turn out to have
no effect in general?
Most of the changes here are to fix style bugs. In the NEW_SCHED case,
the relative weights for each priority are determined by the niceweights[]
table. kg-kg_estcpu is limited only by INT_MAX and priorities are
assigned according to relative values of kg-kg_estcpu (code for this is
not shown). The NEW_SCHED case has not been tried since before SMPng
broke scheduling some more by compressing the priority ranges.
It is relatively easy to uncompress the priority ranges if that is
desirable. What range is best?
Jake
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: spam
On Fri, 21 Dec 2001, Julian Stacey wrote: I can only hope that our illustrious congress has grown as tired of spam as I have and will fix the law to simply ban it. -Matt That would help, (most SPAM I receive even in Germany is from USA), but spammers would move offshore from USA still target us, just as most German language spamming is now from countries outside Germany, so presumably German language spammers pay foreign intermediaries or subsidiaries to spam. Hostile counter attacks could supplement laws filtering ... - I got a panic stricken international phone call from a UK spammer near where I used to live, after I mailed threatened to report him to local police /or launch net attacks on his facilities. - Anyone know of PD sourced tools indexes that automate co-ordination of hostile counter attacks on identified spammers ? Don't counterattack, you have to be 250% sure the server is the spammers own, and his alone. What if the spammer either is just a client, or has broken into the server? It is not legal to break your neigbours house, even if it is to shut down his 500W stereo. I believe somebody got into serious trouble by launching a worm, which closed holes other worms could use. PS Maybe if we were to regularly automatically scramble all email addresses in our web searchable mail archives ? just inserting ._ErAsE_ThIs_. in every email address would protect us from easy harvesting by simple spammer robots. Yeah, that would help for 3 months or so. Then the harvesters will be adapted. The way to go, I think is procmail based content filters, and dnsbl, like spamcop. I report many spams to spamcop. Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: vm_zeropage priority problems.
On Fri, 21 Dec 2001, John Baldwin wrote: On 21-Dec-01 Bruce Evans wrote: On Fri, 21 Dec 2001, Luigi Rizzo wrote: the original priority should be somewhere and accessible, either directly or through some function. Otherwise how do we know what to pass to tsleep() ? It's whatever the thread set itself. There is no good way of setting this either (vm_pagezero() and poll_idle() hack it into td-td_ksegrp-kg_pri). Userland would use rtprio(2) instead. Unfortunately, this gives priorities in different units than the ones for tsleep(). pri_level is the current priority of the thread. The actual priority level is going to move back into the thread and out of the KSE group so that tsleep and priority propagation work properly, but pri_native, pri_user, and nice will stay in the KSE group. The normal priorities for tsleep() are just a subset This will make encapsulating priority stuff on a struct more obviously wrong. of the priorities available to a thread. Thus, they are using the same unit, but perhaps a wider range. They are offset by PRI_MIN_IDLE too, due to vestiges of the rtprio() misimplementation. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: MEXTFREE
On Sat, Dec 22, 2001 at 12:54:16AM -0700, Chad David wrote: MEXTFREE results in a call to _mext_free() which is only defined within subr_mbuf.c, and is not static. Should the prototype be moved into sys/mbuf.h, or should MEXTFREE be moved into subr_mbuf.c, or is it ok like this? It should stay like this. The easy (macro) case deals with only the reference count issue. We only call the function if we really have to free the object (i.e. ref count is dropped to zero). Thanks. -- Chad David[EMAIL PROTECTED] ACNS Inc. Calgary, Alberta Canada -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: vm_zeropage priority problems.
On Sat, 22 Dec 2001, Luigi Rizzo wrote: On Sat, Dec 22, 2001 at 06:48:26PM +1100, Bruce Evans wrote: Most of the changes here are to fix style bugs. In the NEW_SCHED case, the relative weights for each priority are determined by the niceweights[] table. kg-kg_estcpu is limited only by INT_MAX and priorities are assigned according to relative values of kg-kg_estcpu (code for this is not shown). i guess the latter is the hard part... what kind of complexity does it have ? Not too bad. I use an extra loop in schedcpu() to find the current maximum of all kg-kg_estcpu, and convert the divison by this maximum (for scaling individual kg-kg_estcpu's) to a multiplication and a shift. This can probably be done better in loadav(). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: MEXTFREE
On Sat, 22 Dec 2001, Bosko Milekic wrote: On Sat, Dec 22, 2001 at 12:54:16AM -0700, Chad David wrote: MEXTFREE results in a call to _mext_free() which is only defined within subr_mbuf.c, and is not static. Should the prototype be moved into sys/mbuf.h, or should MEXTFREE be moved into subr_mbuf.c, or is it ok like this? It should stay like this. The easy (macro) case deals with only the reference count issue. We only call the function if we really have to free the object (i.e. ref count is dropped to zero). But clients that use MEXTFREE (if any) see the function call, so they need a prototype in scope. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: vm_zeropage priority problems.
On Sat, 22 Dec 2001, Jake Burkholder wrote:
Apparently, On Sat, Dec 22, 2001 at 06:48:26PM +1100,
Bruce Evans said words to the effect of;
Index: kern_synch.c
===
RCS file: /home/ncvs/src/sys/kern/kern_synch.c,v
retrieving revision 1.167
diff -u -2 -r1.167 kern_synch.c
--- kern_synch.c18 Dec 2001 00:27:17 - 1.167
+++ kern_synch.c19 Dec 2001 16:01:26 -
@@ -936,18 +1058,18 @@
struct thread *td;
{
- struct kse *ke = td-td_kse;
- struct ksegrp *kg = td-td_ksegrp;
+ struct ksegrp *kg;
- if (td) {
- ke-ke_cpticks++;
- kg-kg_estcpu = ESTCPULIM(kg-kg_estcpu + 1);
- if ((kg-kg_estcpu % INVERSE_ESTCPU_WEIGHT) == 0) {
- resetpriority(td-td_ksegrp);
- if (kg-kg_pri.pri_level = PUSER)
- kg-kg_pri.pri_level = kg-kg_pri.pri_user;
- }
- } else {
+ if (td == NULL)
panic(schedclock);
- }
+ td-td_kse-ke_cpticks++;
+ kg = td-td_ksegrp;
+#ifdef NEW_SCHED
+ kg-kg_estcpu += niceweights[kg-kg_nice - PRIO_MIN];
+#else
+ kg-kg_estcpu++;
+#endif
+ resetpriority(kg);
+ if (kg-kg_pri.pri_level = PUSER)
+ kg-kg_pri.pri_level = kg-kg_pri.pri_user;
}
I'm curious why you removed the ESTCPULIM and INVERSE_ESTCPU_WEIGHT
calculations even in the OLD_SCHED case. Do these turn out to have
no effect in general?
ESTCPULIM basically breaks scheduling if it is are hit (clipping to it
prevents accumulation of hog points that would cause cpu hogs to be
run less). This is a problem in practice. I use dynamic limits even
in the !NEW_SCHED case. I forgot that I did this or I would have included
more context to show it (see below). kg-kg_estcpu is allowed to grow
without explicit limit and scaled to fit in the priority range. This
requires fixing sorcerer's-apprentice growth of kg_estcpu in fork()
and exit(). kg_estcpu has natural limits but they are quite large
(a constant multiple of the load average).
INVERSE_ESTCPU_WEIGHT is not used because it goes with static scaling,
and % INVERSE_ESTCPU_WEIGHT optimization (which depends on the internals
of resetpriority()) is not so easy to do.
Here are the corresponding changes for resetpriority():
%%%
Index: kern_synch.c
===
RCS file: /home/ncvs/src/sys/kern/kern_synch.c,v
retrieving revision 1.167
diff -u -2 -r1.167 kern_synch.c
--- kern_synch.c18 Dec 2001 00:27:17 - 1.167
+++ kern_synch.c22 Dec 2001 07:34:15 -
@@ -844,15 +949,32 @@
register struct ksegrp *kg;
{
+ u_int estcpu;
register unsigned int newpriority;
mtx_lock_spin(sched_lock);
if (kg-kg_pri.pri_class == PRI_TIMESHARE) {
- newpriority = PUSER + kg-kg_estcpu / INVERSE_ESTCPU_WEIGHT +
+ estcpu = kg-kg_estcpu;
+ if (estcpu estcpumax)
+ estcpu = estcpumax;
+#ifdef NEW_SCHED
+ newpriority = PUSER +
+ (((u_int64_t)estcpu * estcpumul) ESTCPU_SHIFT);
+#else
+ newpriority = PUSER +
+ (((u_int64_t)estcpu * estcpumul) ESTCPU_SHIFT) +
NICE_WEIGHT * (kg-kg_nice - PRIO_MIN);
- newpriority = min(max(newpriority, PRI_MIN_TIMESHARE),
- PRI_MAX_TIMESHARE);
+#endif
+ if (newpriority PUSER)
+ newpriority = PUSER;
+ if (newpriority PRI_MAX_TIMESHARE) {
+ Debugger(newpriority botch);
+ newpriority = PRI_MAX_TIMESHARE;
+ }
kg-kg_pri.pri_user = newpriority;
- }
- maybe_resched(kg);
+ maybe_resched(kg, newpriority);
+ } else
+ /* XXX doing anything here is dubious. */
+ /* XXX was: need_resched(). */
+ maybe_resched(kg, kg-kg_pri.pri_user);
mtx_unlock_spin(sched_lock);
}
%%%
Most of the changes here are to fix style bugs. In the NEW_SCHED case,
the relative weights for each priority are determined by the niceweights[]
table. kg-kg_estcpu is limited only by INT_MAX and priorities are
assigned according to relative values of kg-kg_estcpu (code for this is
not shown). The NEW_SCHED case has not been tried since before SMPng
broke scheduling some more by compressing the priority ranges.
It is relatively easy to uncompress the priority ranges if that is
desirable. What range is best?
The original algorithm works best with something close to the old range
of 50-127 (PUSER = 50, MAXPRI = 127) for positively niced processes alone.
This gives unniced processes a priority range of 50-127 and permits
nice -20'ed processes to have a much larger (numerically) base priority
than unniced ones while still allowing
Re: cvs commit: src/usr.bin/ftp Makefile cmds.c cmdtab.c complet
Hi,
On Fri, 14 Dec 2001 08:43:49 +0200 (SAT)
John Hay [EMAIL PROTECTED] said:
On 13-Dec-2001 Mike Heffner wrote:
| mikeh 2001/12/13 15:46:45 PST
jhay ...
| Log:
| Connect lukemftp to the build as the default ftp client. Lukemftp
| supports most of the previous features of FreeBSD ftp, but has been
| better maintained and includes new features.
Short summary of differences:
jhay ...
Differences/Losses:
*) FTP_PASSIVE_MODE vs. FTP_MODE
*) -4/-6 for forcing IPV4/IPV6
jhay Any chance of getting -4/-6 or something like it, back? It is very useful
jhay here in our environment that have a lot of dual-stack machines.
I think it is still useful in the environment where IPv6 link is
relatively slow than IPv4 link.
How about this patch?
Index: contrib/lukemftp/src/fetch.c
===
RCS file: /home/ncvs/src/contrib/lukemftp/src/fetch.c,v
retrieving revision 1.1.1.1
diff -u -u -r1.1.1.1 fetch.c
--- contrib/lukemftp/src/fetch.c19 Jul 2001 16:26:13 - 1.1.1.1
+++ contrib/lukemftp/src/fetch.c22 Dec 2001 14:47:28 -
@@ -617,7 +617,7 @@
memset(hints, 0, sizeof(hints));
hints.ai_flags = 0;
- hints.ai_family = AF_UNSPEC;
+ hints.ai_family = family;
hints.ai_socktype = SOCK_STREAM;
hints.ai_protocol = 0;
error = getaddrinfo(host, NULL, hints, res0);
Index: contrib/lukemftp/src/ftp.1
===
RCS file: /home/ncvs/src/contrib/lukemftp/src/ftp.1,v
retrieving revision 1.1.1.1
diff -u -u -r1.1.1.1 ftp.1
--- contrib/lukemftp/src/ftp.1 19 Jul 2001 16:26:13 - 1.1.1.1
+++ contrib/lukemftp/src/ftp.1 22 Dec 2001 14:47:29 -
@@ -77,7 +77,7 @@
Internet file transfer program
.Sh SYNOPSIS
.Nm
-.Op Fl AadefginpRtvV
+.Op Fl 46AadefginpRtvV
.Bk -words
.Op Fl o Ar output
.Ek
@@ -146,6 +146,14 @@
Options may be specified at the command line, or to the
command interpreter.
.Bl -tag -width port
+.It Fl 4
+Forces
+.Nm
+to use IPv4 addresses only.
+.It Fl 6
+Forces
+.Nm
+to use IPv6 addresses only.
.It Fl A
Force active mode ftp.
By default,
Index: contrib/lukemftp/src/ftp.c
===
RCS file: /home/ncvs/src/contrib/lukemftp/src/ftp.c,v
retrieving revision 1.1.1.1
diff -u -u -r1.1.1.1 ftp.c
--- contrib/lukemftp/src/ftp.c 19 Jul 2001 16:26:14 - 1.1.1.1
+++ contrib/lukemftp/src/ftp.c 22 Dec 2001 14:47:31 -
@@ -149,7 +149,7 @@
memset(hints, 0, sizeof(hints));
portnum = parseport(port, FTP_PORT);
hints.ai_flags = AI_CANONNAME;
- hints.ai_family = AF_UNSPEC;
+ hints.ai_family = family;
hints.ai_socktype = SOCK_STREAM;
hints.ai_protocol = 0;
error = getaddrinfo(host, NULL, hints, res0);
Index: contrib/lukemftp/src/ftp_var.h
===
RCS file: /home/ncvs/src/contrib/lukemftp/src/ftp_var.h,v
retrieving revision 1.1.1.1
diff -u -u -r1.1.1.1 ftp_var.h
--- contrib/lukemftp/src/ftp_var.h 19 Jul 2001 16:26:14 - 1.1.1.1
+++ contrib/lukemftp/src/ftp_var.h 22 Dec 2001 14:47:31 -
@@ -279,6 +279,8 @@
GLOBAL charremotepwd[MAXPATHLEN]; /* remote dir */
GLOBAL char *username; /* name of user logged in as. (dynamic) */
+GLOBAL sa_family_t family; /* address family to use for connections */
+
GLOBAL char*ftpport; /* port number to use for FTP connections */
GLOBAL char*httpport; /* port number to use for HTTP connections */
GLOBAL char*gateport; /* port number to use for gateftp connections */
Index: contrib/lukemftp/src/main.c
===
RCS file: /home/ncvs/src/contrib/lukemftp/src/main.c,v
retrieving revision 1.1.1.1
diff -u -u -r1.1.1.1 main.c
--- contrib/lukemftp/src/main.c 19 Jul 2001 16:26:14 - 1.1.1.1
+++ contrib/lukemftp/src/main.c 22 Dec 2001 14:47:32 -
@@ -171,6 +171,7 @@
upload_path = NULL;
isupload = 0;
reply_callback = NULL;
+ family = AF_UNSPEC;
/*
* Get the default socket buffer sizes if we don't already have them.
@@ -255,8 +256,16 @@
}
}
- while ((ch = getopt(argc, argv, Aadefgino:pP:r:RtT:u:vV)) != -1) {
+ while ((ch = getopt(argc, argv, 46Aadefgino:pP:r:RtT:u:vV)) != -1) {
switch (ch) {
+ case '4':
+ family = AF_INET;
+ break;
+
+ case '6':
+ family = AF_INET6;
+ break;
+
case 'A':
activefallback = 0;
passivemode = 0;
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED]
Re: spam
On Thu, 20 Dec 2001, Matthew Dillon wrote: :I'm starting to get spam since I joined this list, and the spam is :coming from freebsd.org. If I'm reading the headers right, it's coming :in through a freebsd.org mail server. Ha. In the last two weeks the amount of personal spam I receive has gone up exponentially. I'm getting around 60 a day now. I'm not surprised that the list is seeing a big increase. I can only hope that our illustrious congress has grown as tired of spam as I have and will fix the law to simply ban it. I doubt it: a) the have secretaries (if at all!) to read the mail b) spam = money the solution must lie in something with authentication. E.g. everyone subscribing to this list has to submit his/her pub key and every message should be signed. I image this as something like a quasi-moderated list. If you post something to the list it will first be read by a moderator. If the moderator agrees on the fact that this is not spam, it _must_ be accepted to the list and thereby the sig / pub key is inserted into a DB. Future mails arriving from the just included submitter will be sent to the list without moderation. Thus the moderator is a a one time check for submitters. only people interested in the subject will pass. spammers wont have the time to get interested in -current internals. (usually). After passing once you are free to post as before. I know many people wont like the idea presented above. But it is the only reasonable check I can think of that would exclude spam while at the same time permitting reasonable open access. Of course I am open to better ideas. greetings, aaron (Vienna) --- COSHER = Completely Open Source, Headers, Engineering, and Research To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
msgdef breaks world
install -C -c -m 644 -o root -g wheel tr_TR.ISO8859-9.out /usr/share/locale/tr_ TR.ISO8859-9/LC_MESSAGES/SYS_LC_MESSAGES install -C -c -m 644 -o root -g wheel uk_UA.ISO8859-5.out /usr/share/locale/uk_ UA.ISO8859-5/LC_MESSAGES/SYS_LC_MESSAGES install: /usr/share/locale/uk_UA.ISO8859-5/LC_MESSAGES/SYS_LC_MESSAGES: No such file or directory *** Error code 71 Stop in /usr/src/share/msgdef. *** Error code 1 Stop in /usr/src/share. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: msgdef breaks world
On Sat, Dec 22, 2001 at 09:32:53AM -0800, Steve Kargl wrote: UA.ISO8859-5/LC_MESSAGES/SYS_LC_MESSAGES install: /usr/share/locale/uk_UA.ISO8859-5/LC_MESSAGES/SYS_LC_MESSAGES: \ No such file or directory *** Error code 71 Stop in /usr/src/share/msgdef. *** Error code 1 Stop in /usr/src/share. Nevermind. This appears to be fixed. Now, for the problem: === share/termcap install -C -c -o root -g wheel -m 444 /usr/src/share/termcap/map3270 /usr/share/misc/map3270 TERM=dumb ex - /usr/src/share/termcap/termcap.src /usr/src/share/termcap/reorder ex: not found *** Error code 127 Stop in /usr/src/share/termcap. *** Error code 1 -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: spam
I would suggest that we use a 'modified' subscription method, where simply being mentionned in the list is enough to subscribe.. Now, before you laugh.. there's a twist.. any address found in the archives is automatically subscribed and that includes in the text.. also any mail not subscribed it treated as if it were a moderated list. i.e. sent for OK to someone. once that peson OKs it the person can send mail. I'd suggest that there be a mailing list of 'moderators' maybe 20 or so people to take the load (I'm talking about -current and -hackers here) the people just 'forward the mail to -current or -hackers if they think it's ok, and delete it if it's spam or if they already saw it go through.. The act of forwarding the mail will subscribe the sender. On Sat, 22 Dec 2001, aaron wrote: On Thu, 20 Dec 2001, Matthew Dillon wrote: :I'm starting to get spam since I joined this list, and the spam is :coming from freebsd.org. If I'm reading the headers right, it's coming :in through a freebsd.org mail server. Ha. In the last two weeks the amount of personal spam I receive has gone up exponentially. I'm getting around 60 a day now. I'm not surprised that the list is seeing a big increase. I can only hope that our illustrious congress has grown as tired of spam as I have and will fix the law to simply ban it. I doubt it: a) the have secretaries (if at all!) to read the mail b) spam = money the solution must lie in something with authentication. E.g. everyone subscribing to this list has to submit his/her pub key and every message should be signed. I image this as something like a quasi-moderated list. If you post something to the list it will first be read by a moderator. If the moderator agrees on the fact that this is not spam, it _must_ be accepted to the list and thereby the sig / pub key is inserted into a DB. Future mails arriving from the just included submitter will be sent to the list without moderation. Thus the moderator is a a one time check for submitters. only people interested in the subject will pass. spammers wont have the time to get interested in -current internals. (usually). After passing once you are free to post as before. I know many people wont like the idea presented above. But it is the only reasonable check I can think of that would exclude spam while at the same time permitting reasonable open access. Of course I am open to better ideas. greetings, aaron (Vienna) --- COSHER = Completely Open Source, Headers, Engineering, and Research To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: spam
On Sat, 22 Dec 2001, Julian Elischer wrote: I would suggest that we use a 'modified' subscription method, where simply being mentionned in the list is enough to subscribe.. Now, before you laugh.. there's a twist.. any address found in the archives is automatically subscribed and that includes in the text.. also any mail not subscribed it treated as if it were a moderated list. i.e. sent for OK to someone. once that peson OKs it the person can send mail. I'd suggest that there be (...) the mail will subscribe the sender. Julian, I think your idea and mine were pretty close. I believe the goals are: a) not to slow down -current or -hackers by moderation (= use many moderators as you noted) b) distribute power of moderation (*) c) use technology as much as possible for automation of subscription (thats why I suggested public keys and signatures, since they are a safe indicator that somebody is not imposting as someone else via mail headers) and finally d) keep it as simple as possible I believe your idea would work out great and it would not force people to use gpg/pgp (cf point d). On the other hand signatures seem to be the only way to make sure a certain mail is in fact coming from a subscribed person. Given the current load on -current a process checking each incoming mail for 1) having a sig 2) having a valid sig 3) checking if a certain pub key of a certain subscriber maches the sig - should not be such a problem. Anyway I would like to hear how others feel about that. (*) I could imagine something like: there are n moderators and when the mail arrives m (m n) random moderators are forwarded the new mail. It is sufficient if one of the m moderators accepts the message as not being spam. So if a submitter feels left out by some moderator chances are higher his/her message will be accepted the next time by a different moderator - as long as it is not spam :) If the -current subscribers would want such a scheme I would be happy to help in any way needed. Let me know. greetings, Aaron Kaplan. --- COSHER = Completely Open Source, Headers, Engineering, and Research To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Copy DVD's to CDR -dqofclpjlc
Title: dvd-ad Wish You Could Copy DVD Movies? Now You Can! Click Here For Details ===REMOVE ME
