[Oberon] A4 ? was: Re (2): Oberon Digest, Vol 104, Issue 2
Douglas G. Danforth
danforth at greenwoodfarm.com
Mon Dec 10 22:29:26 CET 2012
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.
On 12/10/2012 3:55 AM, eas lab wrote:
>>> IMO adults/experienced-users shouldn't be using graphical-browsers.
> Bob Walkden writes:-
> 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:
> 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
More information about the Oberon