[Oberon] A4 ? was: Re (2): Oberon Digest, Vol 104, Issue 2
bob at web-options.com
Mon Dec 10 23:04:24 CET 2012
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.
> -----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 &
> > 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
> > 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
> > the book gets cleaner and wiser.
> > With the assistance of USEnet collaborators, I've made a utility
> > 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
> >> 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
> > Yes, you've just reminded me: LEO *IS* 'broken' eg. that when
> > 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
> > 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
> >> 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
> >> 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
More information about the Oberon