[Oberon] A4 ? was: Re (2): Oberon Digest, Vol 104, Issue 2

[Bob Walkden]

Junk email has nothing to do with " adults/experienced-users shouldn't be
using graphical-browsers ".

And not all graphics are eye candy. Chris might as well say adults should
stop eating altogether because so many of them eat sweets.

> Intelligence is being swamped by garbage.

So it seems.

Bob

> -----Original Message-----
> From: Douglas G. Danforth [mailto:danforth at greenwoodfarm.com]
> Sent: 10 December 2012 21:29
> To: ETH Oberon and related systems
> Subject: Re: [Oberon] A4 ? was: Re (2): Oberon Digest, Vol 104, Issue 2
> 
> I actually agree with Chris on his point.
> In 1972 all the email that I received was directed to me and none of it
> was spam (I was at Stanford and we were one of the first 4 nodes on the
> ARPA network).  Information we extracted was text based and was of high
> quality.  In those years I asked myself why wasn't business getting on
> the band wagon and using the internet?
> Well it wasn't until the WWW occur circa 1992 that business finally
> woke up to the potential.  But God, the clutter that they have created!
> I now spend all of my time IGNORING advertising.  That is a horrible
> waste of computer and human time.
> -Doug Danforth
> 
> On 12/10/2012 3:55 AM, eas lab wrote:
> >>> IMO adults/experienced-users shouldn't be using graphical-browsers.
> > Bob Walkden writes:-
> >> why?
> > Eye-candy, like junk-food & smoking can have long-term bad-effects.
> > OTOH, for illiterates: pictures, cartoon & comics are magic &
> effective.
> > In the 90's the ratio of email-lines to intelligent-contents was
> > 40 : 25.    Now its 90-lines envelope for 2.5 lines contents.
> > Intelligence is being swamped by garbage.
> >
> > If you fetch 8 'pages' from a web-site, they'll all contain the SAME
> > 20-80% 'packaging'.  Like in old times, periodicals had 6 part
> > articles, each wrapped in a 40 page periodical.
> >
> > Surfing is going nowhere while waiting to fall off.
> > Browsing is for kiddies. Adults do planned, targetted fetches.
> >
> > So it you want an N-part 'article' from http, you can construct a
> 'book'
> > containing related 'articles' [with TOC on top], conveniently by:
> >      AppendSeparatorLine&URLheaderForALL  FileOfURLs   BookFile
> >
> > But then you find that the appended 'pages' of your book are 70%
> > repetition. Which you can you delete, while reading it.
> > Which is an example of, instead of getting dirty & broken through
> use,
> > the book gets cleaner and wiser.
> >
> > With the assistance of USEnet collaborators, I've made a utility
> which
> > hooks into an editor to:
> >      DeleteAllFurtherCopiesOfThisBlockIgnoringWhiteSpaces..etc.
> > which is good for 20 related-fetches, which are all appended to the
> > same file, and where deleting the inevitable much repeated text is
> > tedious if done manually.
> > ---------------.
> >
> > Jack writes:-
> >> I think another distinction between multithreaded vs task-loop
> >> behavior is the OS vs human attention timeslice, right? Under the
> >> simple task-loop, things like network behavior were inherently
> tricky
> >> to juggle -- do you force the user to wait indefinitely for the FTP
> >> download to complete, or do you slice it up to allow continuation of
> >> other tasks and potentially risk losing the transfer via some future
> threadhog?
> > Yes, you've just reminded me: LEO *IS* 'broken' eg. that when
> running.
> > pop-fetch-mail, it may crash, if I switch to another console/task.
> > I've forgotten about that little problem, since I work-around it eg,
> > by <do append fetches> as described above, and THEN go to
> > LEO-fetch-popmail,
> >
> >> What's nice about AOS as a system is that if you prefer how ETHO
> >> behaves you can live in a System 3 environment (heck, you could
> >> probably construct a V4 environment if that suited you),.
> > I've been using V4 under linux for some years; and like the way it
> > auto detects if the file-to-open is ETHO or linux format, and that
> the
> > font/color selection is ON each text frame.  But I can't understand
> > the <start script> and never figured how to 'invoke it AT any dir-
> tree-node'. Like with LEO:
> > when the contents of any dir is problematic [contains 6 files that
> > need to be read/write/paste together], you just open a new LEO
> 'there'.
> >
> >> and allow a natural interface to a lower-level of the OS that might
> >> want or need to interact with the rest of the planet with a
> different
> >> synchronicity, allowing some kind of blend of an atomic user
> >> interaction with a multifaceted running process.
> > I was hoping that AOS's IDE was better than dumb-typing-in-code from
> > memory, but I never even got to the stage of being able to copy a
> > text-file out of the CD-booted AOS, to a hard-disk or USB-stik.
> > == Chris Glur
> >
> > --
> > Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related
> > systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
> >
> 
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related
> systems https://lists.inf.ethz.ch/mailman/listinfo/oberon