Tillbaka till svenska Fidonet
English   Information   Debug  
ENET.LINGUISTIC   0/13
ENET.POLITICS   0/4
ENET.SOFT   0/11701
ENET.SYSOP   33946
ENET.TALKS   0/32
ENGLISH_TUTOR   0/2000
EVOLUTION   0/1335
FDECHO   0/217
FDN_ANNOUNCE   0/7068
FIDONEWS   24159
FIDONEWS_OLD1   13628/49742
FIDONEWS_OLD2   0/35949
FIDONEWS_OLD3   0/30874
FIDONEWS_OLD4   0/37224
FIDO_SYSOP   12852
FIDO_UTIL   0/180
FILEFIND   0/209
FILEGATE   0/212
FILM   0/18
FNEWS_PUBLISH   4436
FN_SYSOP   41708
FN_SYSOP_OLD1   71952
FTP_FIDO   0/2
FTSC_PUBLIC   0/13615
FUNNY   0/4886
GENEALOGY.EUR   0/71
GET_INFO   105
GOLDED   0/408
HAM   0/16075
HOLYSMOKE   0/6791
HOT_SITES   0/1
HTMLEDIT   0/71
HUB203   466
HUB_100   264
HUB_400   39
HUMOR   0/29
IC   0/2851
INTERNET   0/424
INTERUSER   0/3
IP_CONNECT   719
JAMNNTPD   0/233
JAMTLAND   0/47
KATTY_KORNER   0/41
LAN   0/16
LINUX-USER   0/19
LINUXHELP   0/1155
LINUX   0/22112
LINUX_BBS   0/957
mail   18.68
mail_fore_ok   249
MENSA   0/341
MODERATOR   0/102
MONTE   0/992
MOSCOW_OKLAHOMA   0/1245
MUFFIN   0/783
MUSIC   0/321
N203_STAT   930
N203_SYSCHAT   313
NET203   321
NET204   69
NET_DEV   0/10
NORD.ADMIN   0/101
NORD.CHAT   0/2572
NORD.FIDONET   189
NORD.HARDWARE   0/28
NORD.KULTUR   0/114
NORD.PROG   0/32
NORD.SOFTWARE   0/88
NORD.TEKNIK   0/58
NORD   0/453
OCCULT_CHAT   0/93
OS2BBS   0/787
OS2DOSBBS   0/580
OS2HW   0/42
OS2INET   0/37
OS2LAN   0/134
OS2PROG   0/36
OS2REXX   0/113
OS2USER-L   207
OS2   0/4786
OSDEBATE   0/18996
PASCAL   0/490
PERL   0/457
PHP   0/45
POINTS   0/405
POLITICS   0/29554
POL_INC   0/14731
PSION   103
R20_ADMIN   1123
R20_AMATORRADIO   0/2
R20_BEST_OF_FIDONET   13
R20_CHAT   0/893
R20_DEPP   0/3
R20_DEV   399
R20_ECHO2   1379
R20_ECHOPRES   0/35
R20_ESTAT   0/719
R20_FIDONETPROG...
...RAM.MYPOINT
  0/2
R20_FIDONETPROGRAM   0/22
R20_FIDONET   0/248
R20_FILEFIND   0/24
R20_FILEFOUND   0/22
R20_HIFI   0/3
R20_INFO2   3250
R20_INTERNET   0/12940
R20_INTRESSE   0/60
R20_INTR_KOM   0/99
R20_KANDIDAT.CHAT   42
R20_KANDIDAT   28
R20_KOM_DEV   112
R20_KONTROLL   0/13300
R20_KORSET   0/18
R20_LOKALTRAFIK   0/24
R20_MODERATOR   0/1852
R20_NC   76
R20_NET200   245
R20_NETWORK.OTH...
...ERNETS
  0/13
R20_OPERATIVSYS...
...TEM.LINUX
  0/44
R20_PROGRAMVAROR   0/1
R20_REC2NEC   534
R20_SFOSM   0/341
R20_SF   0/108
R20_SPRAK.ENGLISH   0/1
R20_SQUISH   107
R20_TEST   2
R20_WORST_OF_FIDONET   12
RAR   0/9
RA_MULTI   106
RA_UTIL   0/162
REGCON.EUR   0/2056
REGCON   0/13
SCIENCE   0/1206
SF   0/239
SHAREWARE_SUPPORT   0/5146
SHAREWRE   0/14
SIMPSONS   0/169
STATS_OLD1   0/2539.065
STATS_OLD2   0/2530
STATS_OLD3   0/2395.095
STATS_OLD4   0/1692.25
SURVIVOR   0/495
SYSOPS_CORNER   0/3
SYSOP   0/84
TAGLINES   0/112
TEAMOS2   0/4530
TECH   0/2617
TEST.444   0/105
TRAPDOOR   0/19
TREK   0/755
TUB   0/290
UFO   0/40
UNIX   0/1316
USA_EURLINK   0/102
USR_MODEMS   0/1
VATICAN   0/2740
VIETNAM_VETS   0/14
VIRUS   0/378
VIRUS_INFO   0/201
VISUAL_BASIC   0/473
WHITEHOUSE   0/5187
WIN2000   0/101
WIN32   0/30
WIN95   0/4289
WIN95_OLD1   61583/70272
WINDOWS   0/1517
WWB_SYSOP   0/419
WWB_TECH   0/810
ZCC-PUBLIC   0/1
ZEC   4

 
4DOS   0/134
ABORTION   0/7
ALASKA_CHAT   0/506
ALLFIX_FILE   0/1313
ALLFIX_FILE_OLD1   0/7997
ALT_DOS   0/152
AMATEUR_RADIO   0/1039
AMIGASALE   0/14
AMIGA   0/331
AMIGA_INT   0/1
AMIGA_PROG   0/20
AMIGA_SYSOP   0/26
ANIME   0/15
ARGUS   0/924
ASCII_ART   0/340
ASIAN_LINK   0/651
ASTRONOMY   0/417
AUDIO   0/92
AUTOMOBILE_RACING   0/105
BABYLON5   0/17862
BAG   135
BATPOWER   0/361
BBBS.ENGLISH   0/382
BBSLAW   0/109
BBS_ADS   0/5290
BBS_INTERNET   0/507
BIBLE   0/3563
BINKD   0/1119
BINKLEY   0/215
BLUEWAVE   0/2173
CABLE_MODEMS   0/25
CBM   0/46
CDRECORD   0/66
CDROM   0/20
CLASSIC_COMPUTER   0/378
COMICS   0/15
CONSPRCY   0/899
COOKING   33431
COOKING_OLD1   0/24719
COOKING_OLD2   0/40862
COOKING_OLD3   0/37489
COOKING_OLD4   0/35496
COOKING_OLD5   9370
C_ECHO   0/189
C_PLUSPLUS   0/31
DIRTY_DOZEN   0/201
DOORGAMES   0/2065
DOS_INTERNET   0/196
duplikat   6002
ECHOLIST   0/18295
EC_SUPPORT   0/318
ELECTRONICS   0/359
ELEKTRONIK.GER   1534
Möte FIDONEWS_OLD1, 49742 texter
 lista första sista föregående nästa
Text 11266, 146 rader
Skriven 2005-07-27 14:08:00 av Michiel van der Vlist (2:280/5555)
  Kommentar till text 11262 av Matt Bedynek (1:106/1)
Ärende: Fidonews Echo Rules
===========================
Hello Matt,

 >>> I do not beleive that will solve anything at all.

 MvdV>> Well, you have to keep in mind that because we have an echopol, EC's
 MvdV>> actually have some authority. Or had, when out of area feeds were
 MvdV>> prohobitively expensive. They had the authority to order link cuts.

 > First of all, like the rest of Fidonet these days, your ECs do
 > not operate exactly how ECHOPOL defines them to operate.

I know that some interpret it that way. It does not matter. The ones who work
with it se it different and that is all that matters.

 > Much like policy is used in this zone, only parts that are
 > convenient are used.  That does not mean the practice is bad
 > but that perhaps the document needs revision to define current
 > practice.

There is as much chance of revising EP1 as there is of revising P4. Several
attempts were made, all have failed.

 MvdV>> Yes, that is a problem. Over here the fully connected polygon was
 MvdV>> never very popular. Maybe for the reason you point out. The most
 MvdV>> complex I ever saw in my own region was a simple triangle.

 > My opinion is that it is simply not needed.

I agree. There is no added value in complex polygons. Not today anyway. The
speed advantage is negligible and the SPOF /still/ remains.

 > Everybody wants to be a "big mail hub" but not everyone is cut
 > out for the job.

Indeed....

 > Broadband made becoming a mail distributor too easy.

It has made it affordable, not easier...

 > Not that I have a problem with this but there is more to
 > hubbing mail than setting up a tosser and linking other nodes.
 > When you start forwarding mail, you are responsible for what
 > ever your system injects into the stream.  And, most of the
 > time you are alone in isolating problems and soliciting
 > cooperation to get them fixed.  When someone that hubs fails
 > to do their job they are passing the buck to their peers.
 > That is the current state.

 > Topology grows faster than the network has a need for.

The network is not growing, on the contrary it is shrinking. If we did things
right, the topology hpulkd become less complex. It seems we are doing something
worng...

 > Fidonet is not so mission critical that large meshing is
 > needed.

There never was a need IMHO. There could have been an advantage if we had
introcude flooding techniques as was done in newsnet. A group of German sysops
tried to develop something like that. It failed because it hinged around unique
MSID's and they could not convince the FidoNet community to make MSID's
compulsory.

 > Despite the freedom that broadband has given people.  A
 > coordinated structure (with some technical sanity) runs much
 > better.  Fidonet, as it exists, is a free-for-all.  That is
 > why it needed routing charts (which you were lucky to have
 > updated - if at all).

We never had routing charts in Z2. Not on a zone wide basis anyway.

 > I just remember the technical ceiling of the average hub 10
 > yrs ago being much higher than it is today.

Not just the hubs. Also the average technical competence of the sysops has
dropped markedly.

 > It was cool to see a routed netmail reach the destination in
 > a timely manner even going through a dozen hops!  Today, you
 > are lucky to receive routed netmail even if it has to cross
 > only a few.

Indeed. That is why I try to dliver netmail as close to the destination as
practical these days. To increase the chances of it getting delivered. Routed
netmail is not as reliable as it used to be. Not by far. :-(

 > Not only that, the network was so much larger.  I'd hate to
 > see the state of things in this zone today if the same number
 > of nodes were present.

It would be a mess. Lets' face it, the majority of the technically competent
has left and that comptency is lost forever.

 > Well, I'd like to see the nodes but not the mail problems.  :-)

In your dreams... ;-)

 MvdV>> Yep. And maybe that is why we normally saw just star like distribution
 MvdV>> here. Complex fully connected polygons are difficult to coordinate.

 > That is why we have the current configuration.  Some wanted a
 > five system mesh but I was strongly against it.

And for good reasons I think. The number of links is (almost) proportional with
the square of the number of stars. That means you (almost) double the potential
problems if you go from four to five stars.

 > Instead, I felt satellite meshes composing of no more than
 > three systems was best.  And, there were already mesh
 > clouds operating so why not capitalize on that!

With today's resources one hub can easily feed 50 downlinks. So with four
toplevel hubs each feeding 50 endlevel hubs that in turn each feed 50 end
nodels in a star configuration, we can serve 10.000 nodes. And node node would
be more than five hops away from any other node.

And of course the sensible thing to do would be to make these endlevel hubs the
host of the net that consists of the endnodes they feed. And the four top level
hubs would be the four NCs of a four region FidoNet.

That's all we really need today.

Yeah, I know... Don't wake me up yet, let me enjoy the dream just a little
longer. ;-)

 MvdV>> Also note that over here emphasis was always more on dupe prevention
 MvdV>> rather than dupe detection. In a star like configuration it is fairly
 MvdV>> easy to see what link shoud be cut to break the dupe loop and as I
 MvdV>> said, EC's had the authority to order kink cuts.

 MvdV>> It worked fairly well.

 > You cannot prevent what you cannot control.

One can control it if the configuration is not needlessly complex and one has a
set of rules that everybody follows. (Voluntary or not). As was proven in R28
during the heydays of Fidonet.

Not that it was any better than the anarchism of today, but it proves that it
can be done.

Cheers, Michiel

---
 * Origin: http://www.vlist.nodelist.org (2:280/5555)