Tillbaka till svenska Fidonet
English   Information   Debug  
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/22013
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   900
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/4785
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   1117
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   2814
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/13069
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/340
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/2055
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/4277
WIN95_OLD1   0/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   28592
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/2025
DOS_INTERNET   0/196
duplikat   6000
ECHOLIST   0/18295
EC_SUPPORT   0/318
ELECTRONICS   0/359
ELEKTRONIK.GER   1534
ENET.LINGUISTIC   0/13
ENET.POLITICS   0/4
ENET.SOFT   0/11701
ENET.SYSOP   33806
ENET.TALKS   0/32
ENGLISH_TUTOR   0/2000
EVOLUTION   0/1335
FDECHO   0/217
FDN_ANNOUNCE   0/7068
FIDONEWS   23548
FIDONEWS_OLD1   0/49742
FIDONEWS_OLD2   0/35949
FIDONEWS_OLD3   0/30874
FIDONEWS_OLD4   0/37224
FIDO_SYSOP   12847
FIDO_UTIL   0/180
FILEFIND   0/209
FILEGATE   0/212
FILM   0/18
FNEWS_PUBLISH   4200
FN_SYSOP   41525
FN_SYSOP_OLD1   71952
FTP_FIDO   0/2
FTSC_PUBLIC   0/13586
FUNNY   0/4886
GENEALOGY.EUR   0/71
GET_INFO   105
GOLDED   0/408
HAM   0/16053
HOLYSMOKE   0/6791
HOT_SITES   0/1
HTMLEDIT   0/71
HUB203   466
HUB_100   264
HUB_400   39
HUMOR   0/29
Möte LINUX, 22013 texter
 lista första sista föregående nästa
Text 8028, 383 rader
Skriven 2006-11-17 06:32:47 av mark lewis (1:3634/12.0)
   Kommentar till text 8025 av Maurice Kinal (1:140/13.1)
Ärende: compress.cfg
====================
 ml> i'm still confused as to what you classify as "DOS think"...

 MK> zip would fall into the DOS-think category nicely.  Anything that
 MK> tries to do everything and does any one thing poorly and isn't
 MK> documented.  DOS itself is DOS-think to the extreme and just when
 MK> it started to look like it couldn't get any worse MS decided we all
 MK> wanted and needed a seriously broken GUI based on everything that
 MK> exemplifies what is bad about DOS-think.

 MK> Is that any clearer?

you are making an effort in explaining it, i appreciate that... but you are
using the term in the explanation of it... unless this one line... 

    "Anything that tries to do everything and does any 
     one thing poorly and isn't documented."   

is what you mean...

 ml> things that you classify as "DOS think" i don't find to be because 
 ml> i've always encountered them in other OS environments...

 MK> Me too.  I say let it die already!!!  Jeez.

hehehe...

 ml> hunh? are you talking about the binary PKT and stored messages 
 ml> format?

 MK> I could care less about that but definetly it should have never
 MK> leaked into transfers given it has nothing to do with compatibilty
 MK> of the native hardware employed other then specific codes between
 MK> the computer and the hardware (originally serial POTs modems) which
 MK> mostly were text based as far as the user was concerned wrt
 MK> configuring.

i'm not so sure about most configurations being text based... i was seeing and
using binary configurations long before i ran into my first text based one...
i've never done anything in the mainframe world... i started with a TRS-80
model 1, level 1 with cassette tape storage... i briefly worked with apples and
commodores but have spent the majority of my time on IBM PC compatibles and
that would probably have started with the IBM PCjr... not all of these systems
were running DOS, either... several of them were running XENIX and UNIX... many
of the old Kaypro's come to mind :)

 ml> overcome by the use of another PKT format that is detectable and able 
 ml> to be handled by mail tossers...

 MK> Okay.  How many of those are still in usuage these days?  Argueably

how many of those what?? Type 2, 2+ and 2.0 are all still in use, as far as i
know... that's three type 2 variants...

 MK> none that I've noticed, especially locally.  If I wish to

unfortunately, that is also not so much of a good thing... if you keep closing
all the doors and cutting off access, you won't see the things that are going
on and how they are being used ;)

 MK> communicate via the computer to local people a mailer would be a
 MK> lousy choice and ensure that I am compatible with nobody.  I am not

you are saying this because everyone now days uses the internet instead of the
computer... even back in the heyday of fidonet, not everyone used a mailer,
anyway... only sysops and point systems had those... everyone else used the
bbs...

 MK> sure what you're seeing in your local area but here none of this is
 MK> compatible and one would think there would be something suitable. 

there's nothing wrong with conversion from one format to another... i get news,
email and mailing lists and "convert" them to netmail and echomail... i also
"convert" echos to mailing lists and even have a news server that provides
access to echos stored in my local message base format (JAM)... ain't nothing
to it...

 ml> there are several PKT format proposals in the FTSC archives... 
 ml> some have example codings and handlers but unfortunately none were 
 ml> ever embraced by any tosser coders and thus have languished as 
 ml> nothing more than proposals...

 MK> Right.  I've noticed that as well as proposals that were poorly
 MK> implimented and now we are stuck with the results of that since the
 MK> autors have long abandoned their work for whatever reason, good or
 MK> bad.

not a whole lot we can do about that... we're stuck with what we have or we
implement new stuff and put it to work...

 MK>> preferred over a purely character based format 

 ml> like email and news? the reason is quite simple... no one coded 
 ml> support for it and thus the populace never had a chance to select it 
 ml> for use...

 MK> Yes they have chosen.  That is one reason there are so few users. 
 MK> No? 

no... the users all left for the internet because of the features... features
that you eschew all the time... graphics, streaming video, music, pointy clicky
stuff, etc...

 ml> coders... i'm aware of more than one Type3 PKT format as well as a 
 ml> Type10 format...

 MK> Whatever.  That isn't what we're stuck with though.

there are two type 3 proposals... IIRC, one is an ascii format that is much
like what you desire... but i have to wonder why we have to abandon our
existing methods just because others use another method that is now more
widespread and in more use??

 ml> to implement a new PKT format only takes one to code it and have it 
 ml> supported... in fact, it doesn't even have to be mainstream as long 
 ml> as you can get your feed to support it...

 MK> Both only ship zip and I ship back only raw pkt's which theh
 MK> ***must*** support. Right?  I chose raw pkt's but they both insist
 MK> on supporting what is a questionable practice for whatever reason.

hunh?? your feeds can't ship you raw PKTs?? that's got to be pure BS... what
tossers are they using?? how much traffic are you pulling? what format would
you prefer if not zip?? is it a format that is supported on their platform??

 ml> task as having their current tosser create unbundled (ie: raw) PKTs 
 ml> for your system and then they run a "conversion" tool on them to put 
 ml> them in the plaintext ascii format you desire...

 MK> I used to do that.  I also was using vim as my editor of choice. 
 MK> However that only solves half of the problem and thus I am forced
 MK> to filter incoming via ttylinux which has the 'unzip' function of
 MK> busybox by default.  Since then I have just gone with the flow and
 MK> use hpt/msged to handle raw pkt creation and ship it out that way
 MK> rather then fight against the tide towards obscurity. 

sadly, it isn't that obscure and likely won't be going away for more years to
come... remember, the entire planet used to be connected with these protocols
until the US Gov't decided to open up the internet and commercialize it...

 ml> do such would also be quite easy to implement... it would just need 
 ml> to read the current Type2 PKT files and move the headers to the top 
 ml> while converting from binary to text the current binary data...

 MK> Or not.  Easier to just not worry about it and watch the tide carry
 MK> off everything we call Fido into the vast void of nothingness.

you mean not making the conversion to the format that other network that is
carrying everything off uses??

kinda reminds be of the binkd (IIRC) folk when they first came out... they were
saying, and many agreed with them, that one should be able to use the existing
network protocol layers just as they are and not have to heap other stuff on
top of it to esure that everything works properly... after all, when we use
TCP/IP on a LAN, we don't heap other checks and processes on top of it, do we?
so what they did was to create a mailer that used TCP/IP and basically just
copied the files from one mailer to another relying on nothing more than TCP/IP
and its internal checks and balances... what they found was a bit of a shock to
them... i don't recall what the percentages were but the failures were enough
to cause them to implement some sort of packet checking to ensure that each
piece of the file got to the destination intact... the funny thing is that they
used crc checking and it is very similar to other protocols used in the bbs
world... i don't believe there was an ACK for every piece of the file but there
was some signal when one was broken or never arrived...

 ml> the counter argument to that is that it is faster to transmit e32 
 ml> than 3634... sure, that's only one character but the idea is what 
 ml> we're talking about... it is also easier for programs to work with 
 ml> hex than ascii if the data is needed to be in ascii anyway...

 MK> Sure.

 ml> and before you say it, i don't see how that can be considered "DOS 
 ml> think" ;)

 MK> It doesn't matter what I call it ... does it?

no but that's apparently been your mantra... i'm not trying to be
antagonistic... please don't read me that way... i'm just curious about what
you are saying and why... yes, i also know more about this "DOS think" side and
especially the deeper internals of fidonet protocols cause that's where i've
spent most of my time in fidonet...

 MK>> Last time I checked DOS could handle character based formatting 
 MK>> quite well or as well as DOS could handle any other type of 
 MK>> formatting.

 ml> no, you are right...

 MK> I know I am.  I wrote a DOS-based BBS for myself on that exact
 MK> principle (POTs external modem).  It worked great for the short
 MK> time I used it.  However I moved on and it got lost in the shuffle
 MK> we call progress.  I don't even have a modem anymore and don't miss
 MK> them whatsoever, nevermind DOS.

hehehe... and here i am with several local guys, all running linux of one
flavor or another, and they are all looking for linux compatible modems so they
can provide dialup access and not _have_ to have internet... the cable and
telco down here aren't all that inexpensive... and it is hard for young folk to
pay for these things... much easier to just get and pay for a phone line
without the added expense of an internet account or having to get video
services one doesn't want or need...

 MK>> Seems to me that the last decade has only promoted compatibilty
 MK>> with abandonware which y2k was supposed to have completely
 MK>> obliterated.  

 ml> hunh?? if you are speaking of stuff like QWK then what you are 
 ml> actually witnessing is the average population of users not being 
 ml> willing to give up their existing and favorite tools and methods... 

 MK> Right.  Probably the lot of them can be counted on two hands, maybe
 MK> even one.  I am not aware of anyone locally using anything remotely
 MK> like QWK offline readers. How many there?

you don't get out much do you? drop into the cooking echo and take a peek
about... i'm aware of only two or three folk in there who are sysops and use
message base editors... myself and at least one other... everyone else uses
some form of offline mail... QWK and BW are the two visible formats... i know
that other echos also have similar counts... check the WIN95 echo... similar
stats... stay out of the fido-political areas 'cause those are all going to be
sysops and *C types and they'll mostly be using "sysop editors"... but overall,
most active areas will have a high majority of offline users unless it is an
area that sysop type folk like myself frequent...

 ml> software is still operable today... however, i think you'll see them 
 ml> fall by the wayside in another 31-32 years ;)

 MK> I'd say less then that but we'll see.  Prove me wrong.  I double
 MK> dare you!!!  ;-)

hahaha... well, in 31-32 years, the existing C time code will fall over and
that's the main thing i was looking at... until then, folk will try to fit
stuff into what they like and many like BW and other QWK/BW readers...

ever hear of Waffle BBS written by tom dell? it is/was a *nix oriented bbs that
used the standard *nix formats for storage of mail and news... there was a dos
port of it that also used the same formats... there was a fidonet tosser
written for it... amanda, iirc... i was a tester for it... there was also erin
written by the same guy... one was for netmail/email and the other was for
news/echos... both worked as designed... it sounds like they might have been
what you have been seeking? other than the mailer stuff, i'm not sure how much
closer to pure *nix ways you could get other than those packages... the *nix
version of waffle used the normal shell scripts and userland commands to read
mail and news as well as doing the files thing... there weren't any doorgames
written for waffle, though...

 ml> most all of them left fidonet for various reasons...

 MK> Right.  When the cat is away ...

what mice are there to be playing??

 ml> "failure"... EMSI, on the other hand, was accepted and is actively 
 ml> used today...

 MK> None around here (locally) and if there are they aren't
 MK> identifiable and thus not condusive to growth amongst Fido as a
 MK> whole.  Exactly who are we doing all this for?

what mailers are being used around there?? bink stuff?

  <sound effects> that's so out of date </sound effects>

;)

 ml> have you seen the BBS Documentary, yet?

 MK> Nope.  I saw it all happen.  Did they mention anything about
 MK> VAX/VMS?  :::snicker:::

you'll have to watch it and see... i also saw it all happen but i didn't
personally see every single bit of it happen... were you involved in the
artscene stuff? what about HPAC? or have you always been just a bit-twiddler?
;)

 MK> The first BBS I ever saw was hosted on a VAX/VMS system and had
 MK> nothing to do with Fido.  It was years later before I saw a public
 MK> BBS on a phoneline.  It was very simular except totally different
 MK> as to usage.

i wonder how close it was to CBBS? the original CBBS box was about as big as my
19inch monitor ;)

 ml> it is available from the author for $30 or $40 but it has also 
 ml> been released so that it is free to share... i grabbed a copy of a 
 ml> DVD rip and have watched it a time or two... it is really an 
 ml> eyeopener in some cases... i wasn't as surprised at some of tom 
 ml> jennings statements as i'm sure others possibly were ;)

 MK> That part might be interesting.  I never did talk to him or everr
 MK> see any messages from that direction in all my experience with
 MK> Fido.  I have heard other's claims about him.

tj is/was only one of the many personalities that created the bbs world and the
networks they lived in... there was nothing about RIME/PCRelay which i see
appears to have moved to using fidonet technology to move their mail rather
than their original QWK format which, BTW, was based on the PCBoard message
base format since RIME/PCRelay was mostly PCBoard systems... IIRC, sparky is
also in the BBS Documentary...

 ml> joho,

 MK> Him I am aware of.  He did some really good stuff in his Fido time.

yes, he was one of the first to write an external mailer that could send and
receice fidonet mail or pass the call off to a bbs program in the case of human
callers...

 ml> of GEcho,

 MK> Seen it but never used it myself.  

i used it a little bit but i didn't like some of the stuff its original author
did or was involved in...

 MK> Same with much of the Fido related stuff.  I was more interested 
 MK> in the basic functionality of modems back then and wasn't what you 
 MK> call a regular sysop by any stretch of the imagination.  I was a 
 MK> user on more then just a few 'regular' BBS's though but never 
 MK> thought at the time I wanted or needed to replicate any of it 
 MK> myself.  I miss those days. 

i know that feeling... i've been a sysop for a long time... i guess i spent my
first year or two as a user and then once i found software, i started doing the
sysop thing... i was both and numerous years before the user side of my
activities just simply faded away...

 ml> and numerous others... the PCBoard guys were represented as 
 ml> well as the original Mustang Software (WildCAT!) guys...

 MK> Right.  I remember running across a few of those.  Maximus was the
 MK> usual though or at least later on.

in many areas, yes... it seems that folk ran what others in their area were
running... that way they could get someone to assist them easier... that or
when they were asking around about packages to run, this one or that one were
recommended and many never really looked at any others... myself, i never
really asked anyone... i did ask the operator of the bbs i mainly called about
the PCBoard software he was running... he never answered back... he was one of
those types that didn't want any "competition" and as other members of that bbs
became sysops and he found out, he cut back on their access privs and such...
some of that is even touched on in the documentary...

 ml> terminal applications like ProComm and Telix...

 MK> Telix was a well used one.  

i remember colin samplaneau<sp?> and the first version of Telix that
appeared... i dropped Procomm in the bitbucket right quick and never looked
back... i also remember when jeff woods, from right up the road in raleigh, nc,
moved up there to canada and the reports of the stuff he had to go thru to get
a work permit and such so that he could help colin with Telix... i remember
when colin sold Telix to jeff and jeff moved it back to raleigh... i also
remember a very talented coder that was in the PASCAL echo who was hired by
jeff to do some coding on Telix... i've still got some stuff here by that guy
but don't recall his name right off... it wasn't much later that there was a
version of Telix that was more native to windows...

 MK> I had my own as I required one to work with a Unix based server at 
 MK> the time and there wasn't anything suitable for that then.  I also 
 MK> recall the first time I used Lynx to connect to an networked 
 MK> library database.  Man was that ever a painful experience and now 
 MK> I find myself using it all the time except locally instead of 
 MK> networked.  Times sure change despite remaining exactly the same.

yup... the more things change, the more they stay the same... what is really
goofy is that the average joe thinks that something great and majikal is going
on under the gui hood when in reality, much of it has "regressed" back to the
same formats that have been used for years... much of the same stuff that you
speak of, actually :)  look at the way files are transferred via email... they
are converted to MIME (these days instead of UUENCODE) whereas uucp email
carried the files in their natural state along with the email they were
"attached" to... but even with MIME encoding, there's still a gain in the
file's size that is pretty close to the 3x that UUENCODING gave... ie: a 30k
file would uuencode to about 90k... about the only real plus in today's
networked world is that most all of the old 7bit only systems are gone and as
such, UU and MIME encoding really aren't necessary... they're still used,
though, because it is a convienient method of putting the file /with/ the
message so that they truely travel together...

)\/(ark

 * Origin:  (1:3634/12)