Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #198510 > unrolled thread
| Started by | tech <tech@rkn.ovh> |
|---|---|
| First post | 2018-08-09 19:40 +0200 |
| Last post | 2018-08-11 11:00 +0200 |
| Articles | 20 on this page of 232 — 46 participants |
Back to article view | Back to linux.debian.user
mailing list vs "the futur" tech <tech@rkn.ovh> - 2018-08-09 19:40 +0200
Re: mailing list vs "the futur" Greg Wooledge <wooledg@eeg.ccf.org> - 2018-08-09 19:50 +0200
RE: mailing list vs "the futur" tech <tech@rkn.ovh> - 2018-08-09 20:10 +0200
RE: mailing list vs "the futur" tech <tech@rkn.ovh> - 2018-08-09 20:20 +0200
RE: mailing list vs "the futur" deloptes <deloptes@gmail.com> - 2018-08-10 01:30 +0200
Re: mailing list vs "the futur" David Wright <deblis@lionunicorn.co.uk> - 2018-08-10 03:10 +0200
Re: mailing list vs "the futur" Dan Ritter <dsr@randomstring.org> - 2018-08-10 12:30 +0200
Re: mailing list vs "the futur" Rich Kulawiec <rsk@gsp.org> - 2018-08-10 13:30 +0200
Re: mailing list vs "the futur" Curt <curty@free.fr> - 2018-08-10 14:00 +0200
Re: mailing list vs "the futur" Dan Purgert <dan@djph.net> - 2018-08-10 14:00 +0200
Re: mailing list vs "the futur" Erik Christiansen <dvalin@internode.on.net> - 2018-08-10 14:40 +0200
Re: mailing list vs "the futur" Michael Stone <mstone@debian.org> - 2018-08-10 15:00 +0200
Re: mailing list vs "the futur" Dan Purgert <dan@djph.net> - 2018-08-10 15:10 +0200
Re: mailing list vs "the futur" Rich Kulawiec <rsk@gsp.org> - 2018-08-10 14:50 +0200
Re: mailing list vs "the futur" Dave Sherohman <dave@sherohman.org> - 2018-08-10 15:00 +0200
Re: mailing list vs "the futur" Dan Ritter <dsr@randomstring.org> - 2018-08-10 16:20 +0200
Re: mailing list vs "the futur" The Wanderer <wanderer@fastmail.fm> - 2018-08-10 15:00 +0200
Re: mailing list vs "the futur" cyaiplexys <cyaiplexys@sitesplace.net> - 2018-08-10 18:00 +0200
Re: mailing list vs "the futur" Brad Rogers <brad@fineby.me.uk> - 2018-08-10 15:20 +0200
Re: mailing list vs "the futur" Dan Purgert <dan@djph.net> - 2018-08-10 15:30 +0200
Re: mailing list vs "the futur" "Michelle Konzack" <linux4michelle@tamay-dogan.net> - 2018-08-11 11:00 +0200
Re: mailing list vs "the futur" Dan Purgert <dan@djph.net> - 2018-08-12 14:30 +0200
Re: mailing list vs "the futur" Michael Stone <mstone@debian.org> - 2018-08-10 15:30 +0200
Re: mailing list vs "the futur" "Michelle Konzack" <linux4michelle@tamay-dogan.net> - 2018-08-11 10:40 +0200
Re: Re: mailing list vs "the futur" dekkzz78@gmail.com - 2018-08-11 11:10 +0200
Re: mailing list vs "the futur" Zenaan Harkness <zenaan@freedbms.net> - 2018-08-12 15:50 +0200
Re: mailing list vs "the futur" Dan Purgert <dan@djph.net> - 2018-08-10 13:50 +0200
Re: mailing list vs "the futur" Dan Ritter <dsr@randomstring.org> - 2018-08-10 16:20 +0200
Re: mailing list vs "the futur" rhkramer@gmail.com - 2018-08-23 22:10 +0200
Re: mailing list vs "the futur" Dan Ritter <dsr@randomstring.org> - 2018-08-23 22:30 +0200
Re: mailing list vs "the futur" Celejar <celejar@gmail.com> - 2018-09-05 03:50 +0200
Re: mailing list vs "the futur" "James H. H. Lampert" <jamesl@touchtonecorp.com> - 2018-08-09 21:30 +0200
Re: mailing list vs "the futur" Dan Purgert <dan@djph.net> - 2018-08-10 12:30 +0200
Re: mailing list vs "the futur" rhkramer@gmail.com - 2018-08-23 21:30 +0200
Re: mailing list vs "the futur" "Martin McCormick" <martin.m@suddenlink.net> - 2018-08-23 23:00 +0200
Re: mailing list vs "the futur" Piotr Martyniuk <zaxonxp45@gmail.com> - 2018-08-24 08:10 +0200
Re: mailing list vs "the futur" Zenaan Harkness <zenaan@freedbms.net> - 2018-08-24 08:30 +0200
Re: mailing list vs "the futur" Piotr Martyniuk <zaxonxp45@gmail.com> - 2018-08-24 09:00 +0200
Re: mailing list vs "the futur" Zenaan Harkness <zenaan@freedbms.net> - 2018-08-24 11:50 +0200
Re: mailing list vs "the futur" "Michelle Konzack" <linux4michelle@tamay-dogan.net> - 2018-08-24 21:00 +0200
Re: mailing list vs "the futur" Dan Ritter <dsr@randomstring.org> - 2018-08-24 21:20 +0200
Re: mailing list vs "the futur" The Wanderer <wanderer@fastmail.fm> - 2018-08-24 22:40 +0200
Re: mailing list vs "the futur" John Hasler <jhasler@newsguy.com> - 2018-08-24 23:50 +0200
Re: mailing list vs "the futur" David Wright <deblis@lionunicorn.co.uk> - 2018-08-25 01:10 +0200
Re: mailing list vs "the futur" John Hasler <jhasler@newsguy.com> - 2018-08-25 02:20 +0200
Re: mailing list vs "the futur" David Wright <deblis@lionunicorn.co.uk> - 2018-08-25 21:10 +0200
Re: mailing list vs "the futur" John Hasler <jhasler@newsguy.com> - 2018-08-25 21:30 +0200
Re: mailing list vs "the futur" David Wright <deblis@lionunicorn.co.uk> - 2018-08-27 17:20 +0200
Re: mailing list vs "the futur" Gene Heskett <gheskett@shentel.net> - 2018-08-27 17:40 +0200
Re: mailing list vs "the futur" Dan Ritter <dsr@randomstring.org> - 2018-08-27 18:30 +0200
Re: mailing list vs "the futur" Michael Stone <mstone@debian.org> - 2018-08-27 22:20 +0200
Re: mailing list vs "the futur" Dan Ritter <dsr@randomstring.org> - 2018-08-27 22:30 +0200
Re: mailing list vs "the futur" Mark Rousell <mark.rousell@signal100.com> - 2018-08-28 10:20 +0200
Re: mailing list vs "the futur" Michael Stone <mstone@debian.org> - 2018-08-28 13:50 +0200
Re: mailing list vs "the futur" Mark Rousell <mark.rousell@signal100.com> - 2018-08-28 15:10 +0200
Re: mailing list vs "the futur" Gene Heskett <gheskett@shentel.net> - 2018-08-28 15:50 +0200
Re: mailing list vs "the futur" Dan Purgert <dan@djph.net> - 2018-08-28 16:40 +0200
Re: mailing list vs "the futur" Gene Heskett <gheskett@shentel.net> - 2018-08-28 20:00 +0200
Re: mailing list vs "the futur" Michael Stone <mstone@debian.org> - 2018-08-28 16:30 +0200
Re: mailing list vs "the futur" <tomas@tuxteam.de> - 2018-08-28 16:30 +0200
Re: mailing list vs "the futur" Michael Stone <mstone@debian.org> - 2018-08-28 16:40 +0200
Re: mailing list vs "the futur" <tomas@tuxteam.de> - 2018-08-28 17:10 +0200
Re: mailing list vs "the futur" Mark Rousell <mark.rousell@signal100.com> - 2018-08-28 17:50 +0200
Re: mailing list vs "the futur" Michael Stone <mstone@debian.org> - 2018-08-28 21:10 +0200
Re: mailing list vs "the futur" Michael Stone <mstone@debian.org> - 2018-08-29 00:40 +0200
Re: mailing list vs "the futur" Mark Rousell <mark.rousell@signal100.com> - 2018-08-29 01:20 +0200
Re: mailing list vs "the futur" Michael Stone <mstone@debian.org> - 2018-08-29 03:10 +0200
Re: mailing list vs "the futur" Dan Purgert <dan@djph.net> - 2018-08-29 03:40 +0200
Re: mailing list vs "the futur" <tomas@tuxteam.de> - 2018-08-29 09:20 +0200
Re: mailing list vs "the futur" John Hasler <jhasler@newsguy.com> - 2018-08-29 17:40 +0200
Re: mailing list vs "the futur" Joe <joe@jretrading.com> - 2018-08-29 17:50 +0200
Re: mailing list vs "the futur" <tomas@tuxteam.de> - 2018-08-29 18:10 +0200
Re: mailing list vs "the futur" John Hasler <jhasler@newsguy.com> - 2018-08-29 19:30 +0200
Re: mailing list vs "the futur" Joe <joe@jretrading.com> - 2018-08-29 19:40 +0200
Re: mailing list vs "the futur" Dan Purgert <dan@djph.net> - 2018-08-30 12:00 +0200
Re: mailing list vs "the futur" Joe <joe@jretrading.com> - 2018-08-30 14:50 +0200
Re: mailing list vs "the futur" Dan Purgert <dan@djph.net> - 2018-08-30 15:50 +0200
Re: mailing list vs "the futur" Joe <joe@jretrading.com> - 2018-08-30 21:30 +0200
Re: mailing list vs "the futur" Dan Purgert <dan@djph.net> - 2018-08-31 12:00 +0200
Re: mailing list vs "the futur" Dave Sherohman <dave@sherohman.org> - 2018-09-04 12:30 +0200
Re: mailing list vs "the futur" Dan Purgert <dan@djph.net> - 2018-09-04 14:00 +0200
Re: mailing list vs "the futur" Gene Heskett <gheskett@shentel.net> - 2018-09-04 15:30 +0200
Re: mailing list vs "the futur" Dan Purgert <dan@djph.net> - 2018-09-04 17:20 +0200
Re: mailing list vs "the futur" Gene Heskett <gheskett@shentel.net> - 2018-09-04 18:10 +0200
Re: mailing list vs "the futur" Dan Purgert <dan@djph.net> - 2018-09-04 18:30 +0200
Re: mailing list vs "the futur" Gene Heskett <gheskett@shentel.net> - 2018-09-04 19:50 +0200
[Off-topic] Was: mailing list vs "the futur" John Hasler <jhasler@newsguy.com> - 2018-09-04 20:20 +0200
Re: [Off-topic] Was: mailing list vs "the futur" Gene Heskett <gheskett@shentel.net> - 2018-09-04 20:30 +0200
Re: mailing list vs "the futur" Liam O'Toole <liam.p.otoole@gmail.com> - 2018-09-05 03:10 +0200
Re: mailing list vs "the futur" Gene Heskett <gheskett@shentel.net> - 2018-09-05 04:10 +0200
Re: mailing list vs "the futur" Jonathan Dowland <jmtd@debian.org> - 2018-09-05 09:50 +0200
Re: mailing list vs "the futur" John Hasler <jhasler@newsguy.com> - 2018-09-04 20:00 +0200
Re: mailing list vs "the futur" Gene Heskett <gheskett@shentel.net> - 2018-09-04 20:30 +0200
[Off-topic] Was: mailing list vs "the futur" John Hasler <jhasler@newsguy.com> - 2018-09-04 20:50 +0200
Re: [Off-topic] Was: mailing list vs "the futur" Default User <hunguponcontent@gmail.com> - 2018-09-04 21:20 +0200
Re: [Off-topic] Was: mailing list vs "the futur" Nicolas George <george@nsup.org> - 2018-09-04 21:50 +0200
Re: mailing list vs "the futur" Eric S Fraga <e.fraga@ucl.ac.uk> - 2018-09-04 17:20 +0200
Re: mailing list vs "the futur" Gene Heskett <gheskett@shentel.net> - 2018-09-04 15:20 +0200
Re: mailing list vs "the futur" "Thomas Schmitt" <scdbackup@gmx.net> - 2018-09-04 16:00 +0200
Re: mailing list vs "the futur" mick crane <mick.crane@gmail.com> - 2018-09-01 12:00 +0200
Re: mailing list vs "the futur" <tomas@tuxteam.de> - 2018-09-01 12:40 +0200
Re: mailing list vs "the futur" John Hasler <jhasler@newsguy.com> - 2018-08-29 18:10 +0200
Re: mailing list vs "the futur" Miles Fidelman <mfidelman@meetinghouse.net> - 2018-08-29 19:00 +0200
Re: mailing list vs "the futur" Miles Fidelman <mfidelman@meetinghouse.net> - 2018-08-29 02:40 +0200
Re: mailing list vs "the futur" <tomas@tuxteam.de> - 2018-08-29 09:40 +0200
Re: mailing list vs "the futur" Gene Heskett <gheskett@shentel.net> - 2018-08-29 12:00 +0200
Re: mailing list vs "the futur" <tomas@tuxteam.de> - 2018-08-29 12:10 +0200
Re: mailing list vs "the futur" Gene Heskett <gheskett@shentel.net> - 2018-08-29 12:20 +0200
Re: mailing list vs "the futur" Gene Heskett <gheskett@shentel.net> - 2018-08-29 12:20 +0200
Re: mailing list vs "the futur" Dan Purgert <dan@djph.net> - 2018-08-29 12:50 +0200
Re: mailing list vs "the futur" Gene Heskett <gheskett@shentel.net> - 2018-08-29 13:10 +0200
Re: mailing list vs "the futur" Dan Purgert <dan@djph.net> - 2018-08-29 14:40 +0200
Re: mailing list vs "the futur" <tomas@tuxteam.de> - 2018-08-29 14:40 +0200
Re: mailing list vs "the futur" Dan Purgert <dan@djph.net> - 2018-08-29 15:00 +0200
Re: mailing list vs "the futur" Gene Heskett <gheskett@shentel.net> - 2018-08-29 17:00 +0200
Re: mailing list vs "the futur" Dan Purgert <dan@djph.net> - 2018-08-29 18:10 +0200
Re: mailing list vs "the futur" Gene Heskett <gheskett@shentel.net> - 2018-08-29 21:20 +0200
Re: mailing list vs "the futur" Dan Purgert <dan@djph.net> - 2018-08-30 12:10 +0200
Re: mailing list vs "the futur" Gene Heskett <gheskett@shentel.net> - 2018-08-30 14:20 +0200
Re: mailing list vs "the futur" John Hasler <jhasler@newsguy.com> - 2018-08-29 17:40 +0200
Re: mailing list vs "the futur" Gene Heskett <gheskett@shentel.net> - 2018-08-29 21:10 +0200
Re: mailing list vs "the futur" John Hasler <jhasler@newsguy.com> - 2018-08-30 00:50 +0200
Re: mailing list vs "the futur" David Wright <deblis@lionunicorn.co.uk> - 2018-08-30 01:00 +0200
Re: mailing list vs "the futur" Bob Bernstein <poobah@ruptured-duck.com> - 2018-09-01 20:10 +0200
Re: mailing list vs "the futur" Gene Heskett <gheskett@shentel.net> - 2018-09-01 22:50 +0200
Re: mailing list vs "the futur" Bob Bernstein <poobah@ruptured-duck.com> - 2018-09-01 23:30 +0200
Re: mailing list vs "the futur" <tomas@tuxteam.de> - 2018-09-02 10:00 +0200
Re: mailing list vs "the futur" John Hasler <jhasler@newsguy.com> - 2018-09-02 15:00 +0200
Re: mailing list vs "the futur" Curt <curty@free.fr> - 2018-09-02 15:20 +0200
Re: mailing list vs "the futur" John Hasler <jhasler@newsguy.com> - 2018-09-02 16:10 +0200
Re: mailing list vs "the futur" Nicolas George <george@nsup.org> - 2018-09-02 16:40 +0200
Re: mailing list vs "the futur" Nicolas George <george@nsup.org> - 2018-09-02 17:20 +0200
Re: mailing list vs "the futur" Joe <joe@jretrading.com> - 2018-09-02 18:20 +0200
Re: mailing list vs "the futur" Dan Purgert <dan@djph.net> - 2018-09-02 17:20 +0200
Re: mailing list vs "the futur" Gene Heskett <gheskett@shentel.net> - 2018-09-02 18:00 +0200
Re: mailing list vs "the futur" Curt <curty@free.fr> - 2018-09-02 18:00 +0200
Re: mailing list vs "the futur" Bob Bernstein <poobah@ruptured-duck.com> - 2018-09-03 07:30 +0200
Re: mailing list vs "the futur" Zenaan Harkness <zenaan@freedbms.net> - 2018-09-03 08:10 +0200
Re: mailing list vs "the futur" Eric S Fraga <e.fraga@ucl.ac.uk> - 2018-09-03 07:40 +0200
Re: mailing list vs "the futur" Dan Purgert <dan@djph.net> - 2018-09-03 13:00 +0200
Re: mailing list vs "the futur" Eric S Fraga <e.fraga@ucl.ac.uk> - 2018-09-03 15:50 +0200
Re: mailing list vs "the futur" Dan Purgert <dan@djph.net> - 2018-09-03 16:30 +0200
Re: mailing list vs "the futur" Jonathan Dowland <jmtd@debian.org> - 2018-09-03 13:30 +0200
Re: mailing list vs "the futur" Dan Purgert <dan@djph.net> - 2018-08-29 12:20 +0200
Re: mailing list vs "the futur" Eric S Fraga <e.fraga@ucl.ac.uk> - 2018-08-29 12:40 +0200
Re: mailing list vs "the futur" mick crane <mick.crane@gmail.com> - 2018-09-01 11:50 +0200
Re: mailing list vs "the futur" Gene Heskett <gheskett@shentel.net> - 2018-09-01 16:00 +0200
Re: mailing list vs "the futur" Michael Stone <mstone@debian.org> - 2018-08-29 13:00 +0200
Re: mailing list vs "the futur" Gene Heskett <gheskett@shentel.net> - 2018-08-29 13:20 +0200
Re: mailing list vs "the futur" <tomas@tuxteam.de> - 2018-08-29 13:40 +0200
Re: mailing list vs "the futur" Joe <joe@jretrading.com> - 2018-08-29 14:00 +0200
Re: mailing list vs "the futur" <tomas@tuxteam.de> - 2018-08-29 14:00 +0200
Re: mailing list vs "the futur" Joe <joe@jretrading.com> - 2018-08-29 14:10 +0200
Re: mailing list vs "the futur" <tomas@tuxteam.de> - 2018-08-29 14:30 +0200
Re: mailing list vs "the futur" Michael Stone <mstone@debian.org> - 2018-08-29 14:30 +0200
Re: mailing list vs "the futur" <tomas@tuxteam.de> - 2018-08-29 14:40 +0200
Re: mailing list vs "the futur" Joe <joe@jretrading.com> - 2018-08-29 14:50 +0200
Re: mailing list vs "the futur" Joe <joe@jretrading.com> - 2018-08-29 14:50 +0200
Re: mailing list vs "the futur" Dan Purgert <dan@djph.net> - 2018-08-29 15:30 +0200
Re: mailing list vs "the futur" Michael Stone <mstone@debian.org> - 2018-08-29 14:50 +0200
Re: mailing list vs "the futur" Dan Purgert <dan@djph.net> - 2018-08-29 14:50 +0200
Re: mailing list vs "the futur" Dan Purgert <dan@djph.net> - 2018-08-28 14:00 +0200
Re: mailing list vs "the futur" Gene Heskett <gheskett@shentel.net> - 2018-08-28 01:10 +0200
Re: mailing list vs "the futur" <tomas@tuxteam.de> - 2018-08-28 09:50 +0200
Re: mailing list vs "the futur" Michael Stone <mstone@debian.org> - 2018-08-28 13:20 +0200
Re: mailing list vs "the futur" Mark Rousell <mark.rousell@signal100.com> - 2018-08-28 14:20 +0200
Re: mailing list vs "the futur" Michael Stone <mstone@debian.org> - 2018-08-28 15:00 +0200
Re: mailing list vs "the futur" Mark Rousell <mark.rousell@signal100.com> - 2018-08-28 16:00 +0200
Re: mailing list vs "the futur" Michael Stone <mstone@debian.org> - 2018-08-28 16:30 +0200
Re: mailing list vs "the futur" Mark Rousell <mark.rousell@signal100.com> - 2018-08-28 18:00 +0200
Re: mailing list vs "the futur" Mark Rousell <mark.rousell@signal100.com> - 2018-08-28 18:10 +0200
Re: mailing list vs "the futur" Michael Stone <mstone@debian.org> - 2018-08-28 19:50 +0200
Re: mailing list vs "the futur" Miles Fidelman <mfidelman@meetinghouse.net> - 2018-08-28 20:30 +0200
Re: mailing list vs "the futur" Mark Rousell <mark.rousell@signal100.com> - 2018-08-28 20:40 +0200
Re: mailing list vs "the futur" Mark Rousell <mark.rousell@signal100.com> - 2018-08-28 20:50 +0200
Re: mailing list vs "the futur" Mark Rousell <mark.rousell@signal100.com> - 2018-08-28 20:30 +0200
Re: mailing list vs "the futur" John Hasler <jhasler@newsguy.com> - 2018-08-28 22:30 +0200
Re: mailing list vs "the futur" Mark Rousell <mark.rousell@signal100.com> - 2018-08-28 18:00 +0200
Re: mailing list vs "the futur" Michael Stone <mstone@debian.org> - 2018-08-28 19:50 +0200
Re: mailing list vs "the futur" Miles Fidelman <mfidelman@meetinghouse.net> - 2018-08-28 20:30 +0200
Re: mailing list vs "the futur" Mark Rousell <mark.rousell@signal100.com> - 2018-08-28 16:10 +0200
Re: mailing list vs "the futur" Mark Rousell <mark.rousell@signal100.com> - 2018-08-28 10:20 +0200
Re: mailing list vs "the futur" David Wright <deblis@lionunicorn.co.uk> - 2018-08-27 19:10 +0200
Re: mailing list vs "the futur" Gene Heskett <gheskett@shentel.net> - 2018-08-28 01:20 +0200
Re: mailing list vs "the futur" John Hasler <jhasler@newsguy.com> - 2018-08-28 05:50 +0200
Re: mailing list vs "the futur" Richard Owlett <rowlett@cloud85.net> - 2018-08-25 12:20 +0200
Re: mailing list vs "the futur" John Hasler <jhasler@newsguy.com> - 2018-08-25 14:20 +0200
Re: mailing list vs "the futur" Richard Owlett <rowlett@cloud85.net> - 2018-08-25 15:30 +0200
Re: mailing list vs "the futur" Rodolfo Medina <rodolfo.medina@gmail.com> - 2018-08-24 15:30 +0200
Re: mailing list vs "the futur" Gene Heskett <gheskett@shentel.net> - 2018-08-24 18:20 +0200
Re: mailing list vs "the futur" Curt <curty@free.fr> - 2018-08-24 18:40 +0200
Re: mailing list vs "the futur" Reco <recoverym4n@gmail.com> - 2018-08-24 19:20 +0200
Re: mailing list vs "the futur" "Thomas Schmitt" <scdbackup@gmx.net> - 2018-08-24 19:50 +0200
Re: mailing list vs "the futur" Eric S Fraga <e.fraga@ucl.ac.uk> - 2018-08-24 19:50 +0200
Re: mailing list vs "the futur" Reco <recoverym4n@gmail.com> - 2018-08-24 20:10 +0200
Re: mailing list vs "the futur" mick crane <mick.crane@gmail.com> - 2018-08-24 20:30 +0200
Re: mailing list vs "the futur" Dan Ritter <dsr@randomstring.org> - 2018-08-24 20:50 +0200
Re: mailing list vs "the futur" Zenaan Harkness <zenaan@freedbms.net> - 2018-08-25 01:40 +0200
Re: mailing list vs "the futur" Dave Sherohman <dave@sherohman.org> - 2018-08-27 10:20 +0200
Re: mailing list vs "the futur" rhkramer@gmail.com - 2018-08-27 13:50 +0200
Re: mailing list vs "the futur" <tomas@tuxteam.de> - 2018-08-27 14:20 +0200
Re: mailing list vs "the futur" Gene Heskett <gheskett@shentel.net> - 2018-08-27 16:00 +0200
Re: Re: mailing list vs "the futur" dekkzz78@gmail.com - 2018-08-27 16:20 +0200
Re: mailing list vs "the futur" rhkramer@gmail.com - 2018-08-27 17:30 +0200
Re: mailing list vs "the futur" Eric S Fraga <e.fraga@ucl.ac.uk> - 2018-08-25 10:00 +0200
Re: mailing list vs "the futur" Ben Caradoc-Davies <ben@transient.nz> - 2018-08-25 02:50 +0200
Re: mailing list is the future (corrected spelling mistakes) Brad Rogers <brad@fineby.me.uk> - 2018-08-09 20:10 +0200
Re: mailing list vs "the futur" Ric Moore <wayward4now@gmail.com> - 2018-08-09 21:10 +0200
Re: mailing list vs "the futur" Zenaan Harkness <zenaan@freedbms.net> - 2018-08-12 16:00 +0200
Re: mailing list vs "the futur" Ben Finney <bignose@debian.org> - 2018-08-09 22:20 +0200
Re: mailing list vs "the futur" "Michelle Konzack" <linux4michelle@tamay-dogan.net> - 2018-08-11 11:10 +0200
Re: mailing list vs "the futur" Zenaan Harkness <zenaan@freedbms.net> - 2018-08-12 16:10 +0200
Re: mailing list vs "the futur" Rich Kulawiec <rsk@gsp.org> - 2018-08-10 01:40 +0200
Re: mailing list vs "the futur" Mark Rousell <mark.rousell@signal100.com> - 2018-08-11 00:00 +0200
Re: mailing list vs "the futur" Rob van der Putten <rob@sput.nl> - 2018-08-11 11:50 +0200
Re: mailing list vs "the futur" Zenaan Harkness <zenaan@freedbms.net> - 2018-08-12 16:20 +0200
Re: mailing list vs "the futur" Miles Fidelman <mfidelman@meetinghouse.net> - 2018-08-12 20:10 +0200
Re: mailing list vs "the futur" Dan Purgert <dan@djph.net> - 2018-08-13 12:30 +0200
Re: mailing list vs "the futur" Zenaan Harkness <zenaan@freedbms.net> - 2018-08-13 16:00 +0200
Re: mailing list vs "the futur" Dan Purgert <dan@djph.net> - 2018-08-13 12:30 +0200
Re: mailing list vs "the futur" Darac Marjal <mailinglist@darac.org.uk> - 2018-08-10 10:30 +0200
Re: mailing list vs "the futur" Jonathan Dowland <jmtd@debian.org> - 2018-08-10 12:00 +0200
Re: mailing list vs "the futur" Shea Alterio <krusete@gmail.com> - 2018-08-10 18:50 +0200
Re: mailing list vs "the futur" <tomas@tuxteam.de> - 2018-08-10 12:50 +0200
Re: mailing list vs "the futur" Eric S Fraga <e.fraga@ucl.ac.uk> - 2018-08-11 14:30 +0200
Re: mailing list vs "the futur" <tomas@tuxteam.de> - 2018-08-11 15:30 +0200
Re: mailing list vs "the futur" Greg Wooledge <wooledg@eeg.ccf.org> - 2018-08-13 15:30 +0200
Re: mailing list vs "the futur" <tomas@tuxteam.de> - 2018-08-13 16:00 +0200
Re: mailing list vs "the futur" Zenaan Harkness <zenaan@freedbms.net> - 2018-08-13 16:20 +0200
Re: mailing list vs "the futur" Mark Rousell <mark.rousell@signal100.com> - 2018-08-11 00:00 +0200
Re: mailing list vs "the futur" arne <sp113438@telfort.nl> - 2018-08-11 00:50 +0200
Re: mailing list vs "the futur" dekkzz78@gmail.com - 2018-08-11 11:00 +0200
Page 3 of 12 — ← Prev page 1 2 [3] 4 5 … 12 Next page →
| From | Dan Ritter <dsr@randomstring.org> |
|---|---|
| Date | 2018-08-24 21:20 +0200 |
| Message-ID | <wqpMJ-4er-9@gated-at.bofh.it> |
| In reply to | #199328 |
On Fri, Aug 24, 2018 at 09:52:25PM +0300, Michelle Konzack wrote: > MANY IAP forbid the use of NNTP (e.g. the french Providers Bougues and > Orange) because of the HUGE traffic it produce. NNTP is about the same efficiency as email. Usenet with binaries groups, on the other hand, matches what you are thinking about. > Also you can not access NNTP from mobile devices without killing your > data traffic allowance... As above. > Telia in Estonia has no restrictions, but downloading the index of a > Kernel Devel Newsgroup has just produced 356MByte traffic! WTF? > 96.000 Messages? > > NO THANKS! 96000 messages sounds like a couple of years worth of traffic -- and kernel groups tend to send patches. You're letting specific weird cases frighten you away from a perfectly reasonable protocol. -dsr-
[toc] | [prev] | [next] | [standalone]
| From | The Wanderer <wanderer@fastmail.fm> |
|---|---|
| Date | 2018-08-24 22:40 +0200 |
| Message-ID | <wqr29-4Rx-1@gated-at.bofh.it> |
| In reply to | #199329 |
[Multipart message — attachments visible in raw view] — view raw
On 2018-08-24 at 15:12, Dan Ritter wrote: > On Fri, Aug 24, 2018 at 09:52:25PM +0300, Michelle Konzack wrote: > >> MANY IAP forbid the use of NNTP (e.g. the french Providers Bougues >> and Orange) because of the HUGE traffic it produce. > > NNTP is about the same efficiency as email. > > Usenet with binaries groups, on the other hand, matches what you are > thinking about. Any given news provider can choose not to carry the binaries groups. Any given user can choose not to subscribe to any of the binaries groups. If the user chooses a provider which carries those groups, and chooses to subscribe to one or more of them, then surely that is what that user is choosing to do with the bandwidth which that user purchases from that user's provider - and as long as the user's bandwidth limits are not exceeded, surely it's none of the provider's business what is transported over that bandwidth. >> Telia in Estonia has no restrictions, but downloading the index of >> a Kernel Devel Newsgroup has just produced 356MByte traffic! WTF? >> 96.000 Messages? >> >> NO THANKS! > > 96000 messages sounds like a couple of years worth of traffic -- and > kernel groups tend to send patches. Actually, assuming that this "kernel devel newsgroup" is a gatewayed mirror of the Linux Kernel Mailing List, and based on my archive of the LKML over the course of several years (or my memory of such, as it's on another box to which I don't have immediate access), that's about four to eight months worth of traffic - depending on which year it's from. The per-month message count has been trending upwards over time; it's even possible that by now this might represent as little as three months. (I'm a ways behind.) Yes, it is - or, when I was up to date with such things, was - routine to see well over 20,000 E-mails per month through the LKML. > You're letting specific weird cases frighten you away from a > perfectly reasonable protocol. The LKML is indeed a fairly extreme outlier, however. Very, very few mailing lists get that kind of traffic; it may even be the only one. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
[toc] | [prev] | [next] | [standalone]
| From | John Hasler <jhasler@newsguy.com> |
|---|---|
| Date | 2018-08-24 23:50 +0200 |
| Message-ID | <wqs7V-5t6-9@gated-at.bofh.it> |
| In reply to | #199331 |
The Wanderer writes: > If the user chooses a provider which carries those groups, and chooses > to subscribe to one or more of them, then surely that is what that > user is choosing to do with the bandwidth which that user purchases > from that user's provider - and as long as the user's bandwidth limits > are not exceeded, surely it's none of the provider's business what is > transported over that bandwidth. For marketing reasons they like to advertise very high bandwidth, beyond what they can actually support on shared channels, and then block potentially high-bandwidth services that most of their customers will never use and therefor never miss. -- John Hasler jhasler@newsguy.com Elmwood, WI USA
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2018-08-25 01:10 +0200 |
| Message-ID | <wqtnk-6w1-13@gated-at.bofh.it> |
| In reply to | #199332 |
On Fri 24 Aug 2018 at 16:18:40 (-0500), John Hasler wrote: > The Wanderer writes: > > If the user chooses a provider which carries those groups, and chooses > > to subscribe to one or more of them, then surely that is what that > > user is choosing to do with the bandwidth which that user purchases > > from that user's provider - and as long as the user's bandwidth limits > > are not exceeded, surely it's none of the provider's business what is > > transported over that bandwidth. > > For marketing reasons they like to advertise very high bandwidth, beyond > what they can actually support on shared channels, and then block > potentially high-bandwidth services that most of their customers will > never use and therefor never miss. I thought their concern was usage, not bandwidth (ie speed). 360MB is small beer. Downloading a day's House Judiciary Committee hearing from youtube is around 3-4GB. With TV (all off internet), we use 15-30GB per day. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | John Hasler <jhasler@newsguy.com> |
|---|---|
| Date | 2018-08-25 02:20 +0200 |
| Message-ID | <wqut3-76j-3@gated-at.bofh.it> |
| In reply to | #199334 |
I wrote: > For marketing reasons they like to advertise very high bandwidth, beyond > what they can actually support on shared channels, and then block > potentially high-bandwidth services that most of their customers will > never use and therefor never miss. David writes: > I thought their concern was usage, not bandwidth (ie speed). What sort of providers? Those with shared channels need to worry about bandwidth. -- John Hasler jhasler@newsguy.com Elmwood, WI USA
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2018-08-25 21:10 +0200 |
| Message-ID | <wqM6B-I1-7@gated-at.bofh.it> |
| In reply to | #199336 |
On Fri 24 Aug 2018 at 19:16:35 (-0500), John Hasler wrote: > I wrote: > > For marketing reasons they like to advertise very high bandwidth, beyond > > what they can actually support on shared channels, and then block > > potentially high-bandwidth services that most of their customers will > > never use and therefor never miss. > > David writes: > > I thought their concern was usage, not bandwidth (ie speed). > > What sort of providers? Those with shared channels need to worry about > bandwidth. Sorry, but I was was looking at this from the point of view of we consumers rather than the ISPs. The OP started the discussion, I think, with a pitch to persuade us to prefer channels other than email to follow mailing lists. Some have said that using newsgroups works fine for them. The only mention of speed, bandwidth and usage I've seen was the person who downloaded the Kernel Development index, and that complaint was about its size, not the speed at which it was delivered. I assume the index gets cached somewhere on the user's machine. I can understand that were a mailing list to be delivered via the web on a free service supported by advertising, the discussion of bandwidth would be highly significant, particularly for those on dial-up. Or are you talking about some type of "shared channel" of which I have no knowledge? Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | John Hasler <jhasler@newsguy.com> |
|---|---|
| Date | 2018-08-25 21:30 +0200 |
| Message-ID | <wqMpX-Og-3@gated-at.bofh.it> |
| In reply to | #199371 |
David writes: > Or are you talking about some type of "shared channel" of which I have > no knowledge? Cable providers may have a great many customers on a single cable with large (but limited) bandwidth. Some rural providers may have limited backhaul bandwidth. They make promises to customers based on optimistic estimates of peak usage. -- John Hasler jhasler@newsguy.com Elmwood, WI USA
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2018-08-27 17:20 +0200 |
| Message-ID | <wrrt7-8e8-3@gated-at.bofh.it> |
| In reply to | #199372 |
On Sat 25 Aug 2018 at 14:27:38 (-0500), John Hasler wrote: > David writes: > > Or are you talking about some type of "shared channel" of which I have > > no knowledge? > > Cable providers may have a great many customers on a single cable with > large (but limited) bandwidth. Oh, like me, you mean. When we wanted to get our cable strung from the pole with the least obstructed view of our house, the linesman first told us that all the terminations were taken, but on ringing the office, he found that one line was not subscribed to, so we were able to connect to that pole. When I walk down the back alleys, I can see other poles connected to the same main coax feed that links the poles. I'm still scratching my head why subscribing to NNTP newsgroups should lead to bandwidth problems rather than usage ones. I can hit my bandwidth limits in many other ways like downloading youtube videos, watching TV, etc, but the hard limit is my usage, where I would end up paying money for any excess. > Some rural providers may have limited backhaul bandwidth. They make > promises to customers based on optimistic estimates of peak usage. Now it appears that you're using "usage" where I would write "bandwidth". Am I in a minority of one here? Bandwidth is the rate of transfer of bits, whereas usage is the quantity of bits transferred irrespective of how fast they accumulated. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2018-08-27 17:40 +0200 |
| Message-ID | <wrrMt-8ko-9@gated-at.bofh.it> |
| In reply to | #199427 |
On Monday 27 August 2018 11:11:37 David Wright wrote: > On Sat 25 Aug 2018 at 14:27:38 (-0500), John Hasler wrote: > > David writes: > > > Or are you talking about some type of "shared channel" of which I > > > have no knowledge? > > > > Cable providers may have a great many customers on a single cable > > with large (but limited) bandwidth. > > Oh, like me, you mean. When we wanted to get our cable strung from the > pole with the least obstructed view of our house, the linesman first > told us that all the terminations were taken, but on ringing the > office, he found that one line was not subscribed to, so we were able > to connect to that pole. When I walk down the back alleys, I can see > other poles connected to the same main coax feed that links the poles. > > I'm still scratching my head why subscribing to NNTP newsgroups should > lead to bandwidth problems rather than usage ones. I can hit my > bandwidth limits in many other ways like downloading youtube videos, > watching TV, etc, but the hard limit is my usage, where I would end up > paying money for any excess. > That bandwidth limit is not on your side of the isp, its the bandwidth from the main trunk lines to the isp. NNTP is a huge bandwidth hog regardless of how much of it your isp accepts for spooling on local disk to serve you. > > Some rural providers may have limited backhaul bandwidth. They make > > promises to customers based on optimistic estimates of peak usage. Here at least, thats gradually getting better. > > Now it appears that you're using "usage" where I would write > "bandwidth". Am I in a minority of one here? Bandwidth is the rate of > transfer of bits, whereas usage is the quantity of bits transferred > irrespective of how fast they accumulated. Thats a pretty good view of the differences. > > Cheers, > David. -- Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene>
[toc] | [prev] | [next] | [standalone]
| From | Dan Ritter <dsr@randomstring.org> |
|---|---|
| Date | 2018-08-27 18:30 +0200 |
| Message-ID | <wrsyR-o9-5@gated-at.bofh.it> |
| In reply to | #199435 |
On Mon, Aug 27, 2018 at 11:37:48AM -0400, Gene Heskett wrote:
>
> That bandwidth limit is not on your side of the isp, its the bandwidth
> from the main trunk lines to the isp. NNTP is a huge bandwidth hog
> regardless of how much of it your isp accepts for spooling on local disk
> to serve you.
>
This is not the case.
The NNTP server-to-server algorithm is analogous to rsync,
if you think of:
- each message is a file
- each newsgroup is a directory
- if the receiver doesn't have a directory, it won't be
sync'd over from the sender
- the sender/receiver don't bother looking at contents
of each file to decide whether to update, just the name-timestamp
And it always goes in exactly one direction; when the receiver
wants to send messages back upstream, that's a different
connection in which they swap places.
NNTP is a bandwidth hog in exactly the same proportion as the
space it occupies on disk.
I have simplified for the sake of a familiar analogy.
-dsr-
[toc] | [prev] | [next] | [standalone]
| From | Michael Stone <mstone@debian.org> |
|---|---|
| Date | 2018-08-27 22:20 +0200 |
| Message-ID | <wrw9s-2yo-5@gated-at.bofh.it> |
| In reply to | #199444 |
On Mon, Aug 27, 2018 at 12:28:35PM -0400, Dan Ritter wrote: >On Mon, Aug 27, 2018 at 11:37:48AM -0400, Gene Heskett wrote: >> >> That bandwidth limit is not on your side of the isp, its the bandwidth >> from the main trunk lines to the isp. NNTP is a huge bandwidth hog >> regardless of how much of it your isp accepts for spooling on local disk >> to serve you. >> > >This is not the case. Yes it is. Most ISPs stopped supporting NNTP because of the ridiculous bandwidth (and disk space) demands. Your rebuttal skipped over the part about people posting off-topic junk all over the place, and the fact that (the couple of cranks who actually just wanted to read comp.misc or whatever aside) most people who wanted "newsgroups" really wanted the high volume binary groups with pirated software or movies or whatever--so if an ISP dropped the high volume part of the NNTP feed, they basically had no reason not to drop the whole thing. Back in the late 90s when the handwriting was on the wall it was pushing toward 100GB/day to keep up with a full newsfeed. Remember, disk was a heck of a lot more expensive then. A large ISP could drop a million dollars on a disk array, and only be able to retain a few days worth of traffic. Performance was lousy due to the churn, and people got into the habit of reposting everything basically constantly to counter the fact that retention was so low (driving the load higher and higher). A full newsfeed hit 1TB/day in the early 2000s, and most of the ISPs who were still trying to provide the service threw the towel in at that point. The costs were through the roof, the fraction of customers who used the service was miniscule, and almost nobody canceled because they turned off the news server. At this point I think a full newsfeed is pushing toward 50TB/day. That's a much, much, much smaller fraction of available bandwidth than it was 20 years ago, but here's the thing--the vast majority of everything on the news feed *is never looked at by a human*. That makes the case for keeping a server around really hard to justify for most ISPs. It's a wasteful and inefficient protocol that basically moves enormous quantities of bits around the world, then throws them away. There's a reason usenet is effectively dead. It was a great idea technically, on a "safe" network. It's completely incapable of dealing with abuse on the open internet. In theory you can still use an NNTP client (vs a server) to follow a limited number of text-only groups fairly efficiently. In practice there's just not that much left worth following because the experience got to be so bad, and because so few people are even aware it exists anymore. If you purchase newsgroup service as a standalone from a specialized company you typically get a somewhat more curated experience (for a pretty sizable fraction of the total price of your internet connection, to pay the costs outlined above). The reality is that the primary use of these services is downloading pirated software and other binaries.
[toc] | [prev] | [next] | [standalone]
| From | Dan Ritter <dsr@randomstring.org> |
|---|---|
| Date | 2018-08-27 22:30 +0200 |
| Message-ID | <wrwj8-2Bl-5@gated-at.bofh.it> |
| In reply to | #199459 |
On Mon, Aug 27, 2018 at 04:13:30PM -0400, Michael Stone wrote: > On Mon, Aug 27, 2018 at 12:28:35PM -0400, Dan Ritter wrote: > > On Mon, Aug 27, 2018 at 11:37:48AM -0400, Gene Heskett wrote: > > > > > > That bandwidth limit is not on your side of the isp, its the bandwidth > > > from the main trunk lines to the isp. NNTP is a huge bandwidth hog > > > regardless of how much of it your isp accepts for spooling on local disk > > > to serve you. > > > > > > > This is not the case. > > Yes it is. No, it's not. "NNTP is a huge bandwidth hog regardless of how much of it your ISP accepts for spooling on local disk to serve you." Your irrelevant text storm is *entirely* about the case when the ISP tries to accept and propagate binary froups. Which you then go on to acknowledge: > full newsfeed hit 1TB/day in the early 2000s, and most of the ISPs who were ... > server. At this point I think a full newsfeed is pushing toward 50TB/day. ... > In theory you can still use an NNTP client (vs a server) to follow a limited > number of text-only groups fairly efficiently. In practice there's just not That theory is practice. I have about five "upstream" NNTP servers feeding me the groups I want; none of them do binary groups at all. I pay one of them (ten Euros a year). -dsr-
[toc] | [prev] | [next] | [standalone]
| From | Mark Rousell <mark.rousell@signal100.com> |
|---|---|
| Date | 2018-08-28 10:20 +0200 |
| Message-ID | <wrHoe-MO-11@gated-at.bofh.it> |
| In reply to | #199459 |
[Multipart message — attachments visible in raw view] — view raw
On 27/08/2018 21:13, Michael Stone wrote: > On Mon, Aug 27, 2018 at 12:28:35PM -0400, Dan Ritter wrote: >> On Mon, Aug 27, 2018 at 11:37:48AM -0400, Gene Heskett wrote: >>> >>> That bandwidth limit is not on your side of the isp, its the bandwidth >>> from the main trunk lines to the isp. NNTP is a huge bandwidth hog >>> regardless of how much of it your isp accepts for spooling on local >>> disk >>> to serve you. >>> >> >> This is not the case. > > Yes it is. Most ISPs stopped supporting NNTP because of the ridiculous > bandwidth (and disk space) demands. Your rebuttal skipped over the > part about people posting off-topic junk all over the place, and the > fact that (the couple of cranks who actually just wanted to read > comp.misc or whatever aside) most people who wanted "newsgroups" > really wanted the high volume binary groups with pirated software or > movies or whatever--so if an ISP dropped the high volume part of the > NNTP feed, they basically had no reason not to drop the whole thing. > Back in the late 90s when the handwriting was on the wall it was > pushing toward 100GB/day to keep up with a full newsfeed. You appear to be conflating the NNTP protocol with Usenet, the global message transmission network. They are different things. Usenet as we currently know it relies on NNTP but NNTP is not Usenet. Whilst I agree that it is true that ISPs stopped running their own Usenet-linked NNTP servers for the reasons you describe, it is nevertheless wholly false to say that NNTP is the problem in this context. The problem was Usenet and the massive bulk of binary groups. NNTP was not and is not to blame for Usenet's excess. Any distribution protocol would have been a bandwidth hog in those circumstances. > In theory you can still use an NNTP client (vs a server) to follow a > limited number of text-only groups fairly efficiently. In practice > there's just not that much left worth following because the experience > got to be so bad, and because so few people are even aware it exists > anymore. If you purchase newsgroup service as a standalone from a > specialized company you typically get a somewhat more curated > experience (for a pretty sizable fraction of the total price of your > internet connection, to pay the costs outlined above). The reality is > that the primary use of these services is downloading pirated software > and other binaries. Even here, where you recognise that NNTP can be used for discussions just like this mail list, you still seem to viewing NNTP primarily within the context of Usenet. There is no need for NNTP-based discussions to involve the single, federated Usenet system. It is certainly true that NNTP has fallen out of favour for private discussion groups (nothing to do with Usenet) but there are lots of reasons for this (a long and complex discussion in its own right), and Usenet's problems with volume are only peripherally connected to the reduction in the use of NNTP for text-based discussions of the nature carried here. Both mail list-based discussion groups and NNTP-based discussion groups have reduced in popularity as web-based forums have increased in popularity, despite the fact that web-based forums are not an exact replacement for the use cases of either email or NNTP. This change in popularity never had and does not have any connection with the bandwidth requirements of Usenet (regardless of the protocol used to carry it)/ It should be noted that private NNTP-based groups that were not shared with Usenet existed long before ISPs stopped providing Usenet feeds as part of their general service. In truth, NNTP (colloquially but incorrectly referred to as "Usenet") is still a great protocol for private discussions groups such as this mail list and many others likes it, even if few[1] use it. Used in this manner, NNTP is not and *never was* a bandwidth hog. NNTP is probably more bandwidth-efficient overall than an email discussion list and as, or potentially more, bandwidth-efficient than a web-based forum. NNTP may have fallen out of favour for this type of use case (primarily in favour of web forums as things now stand) but it can and does still do the job in a bandwidth-efficient manner. Footnote:- 1: For example, Mozilla still use NNTP discussions groups which are mirrored as email lists. -- Mark Rousell
[toc] | [prev] | [next] | [standalone]
| From | Michael Stone <mstone@debian.org> |
|---|---|
| Date | 2018-08-28 13:50 +0200 |
| Message-ID | <wrKFr-2zU-15@gated-at.bofh.it> |
| In reply to | #199476 |
On Tue, Aug 28, 2018 at 09:15:43AM +0100, Mark Rousell wrote: >You appear to be conflating the NNTP protocol with Usenet, the global message >transmission network. They are different things. Usenet as we currently know it >relies on NNTP but NNTP is not Usenet. > >Whilst I agree that it is true that ISPs stopped running their own >Usenet-linked NNTP servers for the reasons you describe, it is nevertheless >wholly false to say that NNTP is the problem in this context. The problem was >Usenet and the massive bulk of binary groups. NNTP was not and is not to blame >for Usenet's excess. Any distribution protocol would have been a bandwidth hog >in those circumstances. Yes and no. NNTP is inherently open to abuse because it wasn't designed with mechanisms to account for the cost of a transaction. (This is true of all the early internet protocols, not just NNTP, which is why we have, e.g., such a spam problem on SMTP.) But certainly you can identify or deal with an abusive customer on HTTP much easier than you can identify and remediate abuse within the noise of an NNTP feed. I remember the heroic efforts that abuse staff were trying in the mid to late 90s, but it just wasn't possible. SMTP was able to mitigate the worst problems by instituting spam filters and dropping connections from shady corners of the internet--especially open relays. But this was possible even to approach because SMTP involves a known sender and a known receiever, so if a message is lost either the sender or receiever can try to resolve the problem. It's much less clear how you cut off NNTP servers without getting silently-disconnected islands of news and a horrible user experience for everyone. You can "solve" the problem by keeping NNTP in a walled garden (disconnecting from usenet) but then you lose a lot of the inherent advantages of NNTP and end up with a protocol that's kinda overweight for the simple problem of transferring a few text messages in a client/server fashion. In theory it would be nice to just be able to access web-based discussion lists via NNTP so you could use a generic client and customize the interface. But this isn't a thing that's done much; the NNTP protocol is both too complicated and also too lacking in functionality that modern discussion group members look for. There are probably more people using tapatalk for that purpose--even though it's hideous and proprietary--simply because it's a better fit than NNTP for a modern discussion group. Mike Stone
[toc] | [prev] | [next] | [standalone]
| From | Mark Rousell <mark.rousell@signal100.com> |
|---|---|
| Date | 2018-08-28 15:10 +0200 |
| Message-ID | <wrLUS-3ta-21@gated-at.bofh.it> |
| In reply to | #199479 |
[Multipart message — attachments visible in raw view] — view raw
On 28/08/2018 12:42, Michael Stone wrote: > Yes and no. NNTP is inherently open to abuse because it wasn't > designed with mechanisms to account for the cost of a transaction. > (This is true of all the early internet protocols, not just NNTP, > which is why we have, e.g., such a spam problem on SMTP.) Isn't this true of, say, HTTP too? As with your other comments about Usenet, this is not an issue for a non-publicly federated system. I.e. The problem that affected Usenet (the ultimate in publicly federated systems) in this context does not affect NNTP in general for discussion group usage. Remember that we're having this discussion over email. As you observed above, SMTP-based email suffers from a spam problem due to this very issue. And yet this discussion list works. If this list was a NNTP-based discussion group, it would be even more bandwidth-efficient, it would not suffer from deliverability problems that email over SMTP can bring, and moderator-ability would not be an issue either (see below for more on this). > But certainly you can identify or deal with an abusive customer on > HTTP much easier than you can identify and remediate abuse within the > noise of an NNTP feed. This is the issue with what I called "moderator-ability" above. What "noise of an NNTP feed"? A NNTP feed need have no more "noise" than this mail list does. Once again you seem to be conflating NNTP (used in the context of a discussion group like this one or a group of such discussion groups) with the massive volume of Usenet. In fact, there is no difference whatsoever in the ability of moderators to identify and/or deal with abusive users on NNTP-based discussion groups compared to web-based forums. Equally in both cases, abusive messages can be seen by moderators, pre-moderation is potentially possible in both cases, messages can be deleted, and users can be suspended/banned or whatever. The only difference is that deletion of previously posted messages in a web-forum is always visible to everyone whereas message deletion is not retrospectively visible for already-downloaded messages received by NNTP (although this does depend to some extent on client software implementation). Let me say again that the problems that you often ascribe to NNTP are actually problems with Usenet (i.e. a massively and publicly federated system that happened to use NNTP) and are nothing to do with NNTP itself in the scenario under discussion here. > I remember the heroic efforts that abuse staff were trying in the mid > to late 90s, but it just wasn't possible. SMTP was able to mitigate > the worst problems by instituting spam filters and dropping > connections from shady corners of the internet--especially open > relays. But this was possible even to approach because SMTP involves a > known sender and a known receiever, so if a message is lost either the > sender or receiever can try to resolve the problem. It's much less > clear how you cut off NNTP servers without getting > silently-disconnected islands of news and a horrible user experience > for everyone. Again, this is an issue with Usenet, not NNTP. Whilst these things were a problem, I think you are further wrong to compare email to Usenet in this context. The reason I say this is because email in this context is a one-to-one system (i.e. as you say, one known user to one known user in this context) whereas NNTP fulfilled a different use case entirely: It was one-to-many (i.e. one known user to many unknown users). Therefore there was no point in trying to 'fix' Usenet in this context. It was working as intended. Email was fixable because its use case was fundamentally different (even though email can be used for similar things to Usenet). I suspect you might criticise my description of Usenet (or NNTP) as a "one known user to [...]" system but the sender of a Usenet message was known to *exactly* the same extent as a SMTP email sender. In the timeframe under discussion, both Usenet and SMTP email carry the same requirement (or lack thereof) for authentication. There was no difference (either in practice or theory) whatsoever. > You can "solve" the problem by keeping NNTP in a walled garden > (disconnecting from usenet) but then you lose a lot of the inherent > advantages of NNTP and end up with a protocol that's kinda overweight > for the simple problem of transferring a few text messages in a > client/server fashion. Where did you get that idea from? You're still seeing things from a Usenet-centric perspective. There is no need to see things that way. We're not talking about "disconnecting from usenet", as you put it. The use case under discussion here never was connected to Usenet. As I mentioned in another recent message, ISPs were hosting private NNTP-based discussion groups long before they dropped Usenet-connected NNTP servers. There is nothing about NNTP that requires it to be connected to Usenet. You lose nothing whatsoever in the context under discussion here: That is private discussion groups like this mail list. Sharing with Usenet adds nothing whatsoever to this scenario. Furthermore, you characterise NNTP as "kinda overweight for the simple problem of transferring a few text messages in a client/server fashion" and I could not disagree more. NNTP is ideally suited to sharing messages in a client/server fashion. As I have observed, it is more efficient in this regard (in terms of bandwidth-efficiency as well as management efficiency) than email lists and it is at least as efficient in these terms (and likely more bandwidth-efficient) than web forums. > But this isn't a thing that's done much; the NNTP protocol is both too > complicated and also too lacking in functionality that modern > discussion group members look for. It's not done much because NNTP (as well as email lists, albeit slightly less so with mail lists) has fallen out of favour as web forums have increased in popularity. However, as many members of this list have observed, NNTP is still, for those who like it, an ideal method of accessing this kind of discussion. I am surprised to see you say that NNTP is "too complicated". In the medium term future I'll have to implement a NNTP server and, having looked at the RFCs, it doesn't look too bad. Have you experience of implementing NNTP? As for "lacking in functionality", it all depends on what you expect it to provide. As a way of getting messages from place to place, it seems ideal. As a way of providing other features, it depends. I would not, for example, expect NNTP on its own to provide a moderation UI or avatars. Note that modern web forums often provide email alerts (and some allow email participation). The fact that email is as 'primitive' as NNTP in this respect compared to web forums native interfaces does not detract from the fact that it is useful for many users. > There are probably more people using tapatalk for that purpose--even > though it's hideous and proprietary--simply because it's a better fit > than NNTP for a modern discussion group. It all depends. I'm a member of a number of discussion groups: Mail lists, NNTP-based discussion groups, web forums. For me, Tapatalk is, as you say, hideous and proprietary and so it's not a good fit for my uses. For me, all those discussion groups could perhaps better be transmitted to me over NNTP. That would work better for my use case. It would be ideal for me, in fact. Yes, as I have observed, web forums (for which Tapatalk is a front end) have grown in popularity as NNTP and email have declined in popularity but what works best really does depend on the user (and type of user). Note also that the front end user experience is not necessarily directly dependent on the transport protocol. For example, it is entirely feasible for a front end that looks and works much like Tapatalk or like the mobile web versions of popular web forums to communicate with its back end via NNTP, or to communicate with different back ends using a range of protocols (e.g. NNTP, email, REST, and so on). -- Mark Rousell
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2018-08-28 15:50 +0200 |
| Message-ID | <wrMxz-3FQ-3@gated-at.bofh.it> |
| In reply to | #199484 |
On Tuesday 28 August 2018 09:03:05 Mark Rousell wrote: > On 28/08/2018 12:42, Michael Stone wrote: > > Yes and no. NNTP is inherently open to abuse because it wasn't > > designed with mechanisms to account for the cost of a transaction. > > (This is true of all the early internet protocols, not just NNTP, > > which is why we have, e.g., such a spam problem on SMTP.) > > Isn't this true of, say, HTTP too? Yes, and in most cases spamassassin and friends are incapable of dealing with this. Judging any html only message as a very high probability of being spam. And the windows oriented idijits in charge of net services such as my banks online activities, aren't aware of that, so they've been deleting any plain text from their messages. I had a long talk with him just last week about how they are doing this new protocol where they A: don't bother to verify me when I get redirected to their servers for a one time code pad number to verify the authorization of my purchase. B: I pointed out that the current method is dependant on a cookie that exists only on this machine, and likely this browser since palemoon has never worked for this. And that this precludes my ability to goto any machine on my local net, fire up its browser and goto a vendors site and make a purchase. I pointed out to him that he had other means of I'ding me that were both far more universal and would work just as well if this machine was in pieces and I was actually logging on from the browser on my milling machine in the garage. Thats the presence of a list of security questions only I can answer, and which would via the https link that exists, give me that one time pad number without emailing it to far less secure a machine that is in parts on the front deck for its annual dusting and cleaning. He agreed that it was at least as secure and that he would look into implementing it as an alternative way of identifying the account holder. We'll see. Who was it that said words similar to "progress in driven by the obstinate?" I can be that, and proud of it. [...] -- Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene>
[toc] | [prev] | [next] | [standalone]
| From | Dan Purgert <dan@djph.net> |
|---|---|
| Date | 2018-08-28 16:40 +0200 |
| Message-ID | <wrNjX-4aM-5@gated-at.bofh.it> |
| In reply to | #199487 |
Gene Heskett wrote: > On Tuesday 28 August 2018 09:03:05 Mark Rousell wrote: > >> On 28/08/2018 12:42, Michael Stone wrote: >> > Yes and no. NNTP is inherently open to abuse because it wasn't >> > designed with mechanisms to account for the cost of a transaction. >> > (This is true of all the early internet protocols, not just NNTP, >> > which is why we have, e.g., such a spam problem on SMTP.) >> >> Isn't this true of, say, HTTP too? > > [...] I had a long talk with > him just last week about how they are doing this new protocol where they > A: don't bother to verify me when I get redirected to their servers for > a one time code pad number to verify the authorization of my purchase. him who? your bank? -- |_|O|_| Registered Linux user #585947 |_|_|O| Github: https://github.com/dpurgert |O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5 4AEE 8E11 DDF3 1279 A281
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2018-08-28 20:00 +0200 |
| Message-ID | <wrQrv-5VA-3@gated-at.bofh.it> |
| In reply to | #199497 |
On Tuesday 28 August 2018 10:22:34 Dan Purgert wrote: > Gene Heskett wrote: > > On Tuesday 28 August 2018 09:03:05 Mark Rousell wrote: > >> On 28/08/2018 12:42, Michael Stone wrote: > >> > Yes and no. NNTP is inherently open to abuse because it wasn't > >> > designed with mechanisms to account for the cost of a > >> > transaction. (This is true of all the early internet protocols, > >> > not just NNTP, which is why we have, e.g., such a spam problem on > >> > SMTP.) > >> > >> Isn't this true of, say, HTTP too? > > > > [...] I had a long talk with > > him just last week about how they are doing this new protocol where > > they A: don't bother to verify me when I get redirected to their > > servers for a one time code pad number to verify the authorization > > of my purchase. > > him who? your bank? yes, the IT guy=him. -- Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene>
[toc] | [prev] | [next] | [standalone]
| From | Michael Stone <mstone@debian.org> |
|---|---|
| Date | 2018-08-28 16:30 +0200 |
| Message-ID | <wrNah-47Z-1@gated-at.bofh.it> |
| In reply to | #199484 |
On Tue, Aug 28, 2018 at 02:03:05PM +0100, Mark Rousell wrote: >Isn't this true of, say, HTTP too? Not in the same way, because you have a sender and a receiver, without the potentially infinite number of other machines that might be getting a copy of the content just in case someone might want it someday. >As with your other comments about Usenet, this is not an issue for a >non-publicly federated system. I.e. The problem that affected Usenet (the >ultimate in publicly federated systems) in this context does not affect NNTP in >general for discussion group usage. Sure. But in that context, there's not really much benefit to NNTP either. It's just a dumb transport protocol with fewer deployed clients than HTTP. >Remember that we're having this discussion over email. As you observed above, >SMTP-based email suffers from a spam problem due to this very issue. And yet >this discussion list works. If this list was a NNTP-based discussion group, it >would be even more bandwidth-efficient How? Let's just drop the discussion about how horrible usenet was and focus on what the potential benefits of NNTP are. I can't think of many (definitely none significant) over SMTP, and none at all over a well implemented modern web based discussion with a cacheable REST interface. > But certainly you can identify or deal with an abusive customer on HTTP > much easier than you can identify and remediate abuse within the noise of > an NNTP feed. > > >This is the issue with what I called "moderator-ability" above. > >What "noise of an NNTP feed"? A NNTP feed need have no more "noise" than this >mail list does. Once again you seem to be conflating NNTP (used in the context >of a discussion group like this one or a group of such discussion groups) with >the massive volume of Usenet. Well, you also seem to like to jump back and forth in talking about one or the other, without actually offering any specifics. :) You brush off the problems of (the only) large scale NNTP implementation by offering a closed environment with close to zero users as a counterexample. But I'm happy to stop talking about usenet...except that you bring it up again: >I suspect you might criticise my description of Usenet (or NNTP) as a "one >known user to [...]" system but the sender of a Usenet message was known to >exactly the same extent as a SMTP email sender. In the timeframe under >discussion, both Usenet and SMTP email carry the same requirement (or lack >thereof) for authentication. There was no difference (either in practice or >theory) whatsoever. There was, in that you could use a throwaway account to broadcast a message to a large number of effectively anonymous but long-term users. In the SMTP context it's really hard to have throwaway accounts send to other throwaway accounts, allow the content to be durable, and be discoverable. The closest analogy was shared mail accounts used as dropboxes, but the clients of those were easily tracked once the account was identified. >NNTP is ideally suited to sharing messages in a client/server >fashion. As I have observed, it is more efficient in this regard (in terms of >bandwidth-efficiency as well as management efficiency) than email lists and it >is at least as efficient in these terms (and likely more bandwidth-efficient) >than web forums. You've asserted it many times, but you haven't actually shown with numbers how it's more efficient in practice to any degree that matters in the real world. When sending via SMTP you consolidate messages per ISP/mail domain, and the backend mail server can deduplicate (or avoid duplicating) the incoming messages if that's an administrative priority. In practice, the volume of something like the debian lists is so low compared to the volume of background spam it doesn't even really matter. If reading via REST in a caching HTTP environment it's even more efficient since you won't retrieve even a single copy of a message unless it's requested. In practice there's not much caching these days for a variety of reasons but again, compared to the overall volume of web traffic the load of debian discussion groups is too small to matter. >I am surprised to see you say that NNTP is "too complicated". In the medium >term future I'll have to implement a NNTP server and, having looked at the >RFCs, it doesn't look too bad. Have you experience of implementing NNTP? Make sure that your NNTP implementation is interoperable with your web forum, because if it doesn't it's a dead end. (And duplicative--we already have a lot of unused NNTP server code.) It's not that NNTP is necessarily complicated in itself, it's that making it interoperate with the expectations of a modern web forum is hard--potentially impossible without proprietary extensions, at which point you've thrown away the entire point of sticking with NNTP instead of using something else. The conceptual split between transit and reading functionality is a lot of legacy to carry forward if you're basically trying to create a reader interface for smart clients. Enough to make it debatable whether it's worth trying to implement all that vs exposing a REST API. >As for "lacking in functionality", it all depends on what you expect it to >provide. As a way of getting messages from place to place, it seems ideal. As a >way of providing other features, it depends. I would not, for example, expect >NNTP on its own to provide a moderation UI or avatars. And yet, those things have made web forums the de facto replacement for NNTP. As much as greybeards don't understand why the like button matters, it's really hard to convince actual users these days that the reason you don't have one is that they don't need it and you know better than they do. There are a lot of other usability issues that basically boil down to the change in user behavior from using a smart client at one location (possibly telnetting/sshing into there from elsewhere) to using a variety of dumb clients to access centralized resources. Protocols that transfer dumb messages but allow a lot of endpoint customization are great in the smart client model but tend to not have a good user experience in the dumb client model. (And vice versa--if you have the ability to highly customize a specific workstation, it's frustrating to not be able to.) Given demographic and technological trends, ignoring the dumb client paradigm is short sighted at best. >Note also that the front end user experience is not necessarily directly >dependent on the transport protocol. For example, it is entirely feasible for a >front end that looks and works much like Tapatalk or like the mobile web >versions of popular web forums to communicate with its back end via NNTP, or to >communicate with different back ends using a range of protocols (e.g. NNTP, >email, REST, and so on). This is exactly what I was talking about earlier. Yes, it's theoretically possible. But for a variety of real-world reasons, large scale NNTP-accessible web forums haven't succeeded. (If you look, you can find a lot of attempts that never really gained much traction.) It was more practical in the tapatalk case to invent a new protocol than to use NNTP. I'd suggest that it's worth understanding why rather than just insisting that everybody is wrong and NNTP is the answer that they just haven't figured out.
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2018-08-28 16:30 +0200 |
| Message-ID | <wrNah-47Z-3@gated-at.bofh.it> |
| In reply to | #199493 |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Aug 28, 2018 at 10:16:06AM -0400, Michael Stone wrote: > On Tue, Aug 28, 2018 at 02:03:05PM +0100, Mark Rousell wrote: > >Isn't this true of, say, HTTP too? > > Not in the same way, because you have a sender and a receiver, > without the potentially infinite number of other machines that might > be getting a copy of the content just in case someone might want it > someday. To be fair, this only applies to the brave (pre CDN) old world :) Cheers - -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAluFWsAACgkQBcgs9XrR2kbfnQCfQ0lI+rZAe9RsUYZOJmboRKjs A84AnjtkqIdZwH0MYJ6wNfukMxRiNpR/ =GAEE -----END PGP SIGNATURE-----
[toc] | [prev] | [next] | [standalone]
Page 3 of 12 — ← Prev page 1 2 [3] 4 5 … 12 Next page →
Back to top | Article view | linux.debian.user
csiph-web