FreeBSD Bounties

[spellberg_robert]

mr. fromme almost gets to the point that i am about to make.

every so often, some one posts a complaint about another entity's browser.
it can't do this, it can't do that, "blah, blah, woof, woof"
   [ the quote is from jimi hendrix; monterey, 1967, iirc ].

question:  if the "browser_products" of other entities are --so-- problematic,
              just --how-- difficult would it be to "roll our own" ?

note that this question is --not-- the same as asking
   how long it would take to code all of the whiz_bangs
   that the marketing_department_dweebs want to advertise.

it doesn't have to do everything,
   but, what it does do must be done well; reliably, predictably.

i would want it to do things "the bsd way", e. g., search by reg_ex.
it would be totally divorced from anything "gnu".
i don't care about animation [ images hog bandwidth, big_time ].

here is a concept about which i have fantasized for quite some time.
i have been writing a book_keeping app that is
   designed to do certain things that i have not found to exist in
   any of the pre_fab, out_of_the_box, point_and_click thingies,
   which are available for purchase
   [ "ask about our multi_user_license program" ]
   at the big_box store.
for quite some time, off_and_on, admittedly,
   i have been researching how to write a "browser".
it is my understanding that,
   once i can recursively render tables, the rest is comparitively easy.
i have not, just yet, figured_out how to do the secure_http thing
   [ this is where i am stalled ].
i want a program
   that, either, is or, to the outside_world, appears to be a "browser"_like thingy and
   which is --programmable--,
   so that it may, in co_ordination with my book_keeping app,
   log in to any account,
   >----> to which i am already authorized access, <----<
   such as my bank or my electric_utility,
   in the middle_of_the_night, while i am asleep,
   to down_load transaction_events or other postings,
   to up_load bill_payment schedulings or other instructions,
   so that i don't have to use my waking moments to
   do these routine, but, necessary, time_consuming chores.
this is an example of the bsd approach, "routine tasks should be scripted".
further, i want this "browser" to be a "logging" "browser",
   making a disk_copy of --every-- page that comes in,
   text, image, --everything--,
   so that i do not have to remember to "save" a copy of the page,
   even from so_called "secure" sites
   [ i have confidence in my ability to
       secure sensitive information and to manage log_files
   ].

to get to the topic of "bounties",
   it is with deep regret that i inform all readers that,
   "for the duration" of the global_economic_depression,
   presently being engineered by the american donkey political_party,
   with the able assistance of their front_man, the "magic_messiah"
   [ for whose failure, i pray several times per day ],
   i will be unable to supply any funds to the "bounty" program
   [ surely, there is a better word, isn't there ? ].
however, especially after the book_keeping app is working,
   i anticipate having more time available.
as my bsd skills continually improve,
   my confidence in, one day,
   being able to make a credible contribution to the freebsd project
   improves commensurately.

[ an aside to mr. stokely.

   regarding a dialogue in which you took part about a month ago,
     i am pleased to learn that your need is for author people, not mark_up people.
   i frequently find myself making copies of files,
     e. g., "man" pages or "info" docs,
     then, amending them to
     add examples or explanations,
     fix spelling, grammar and punctuation
     [ the comma is great for setting_off subordinate clauses ] errors,
     rewrite tortured phrasing and,
     sometimes, correct content errors.

   "fixing things" may be where i may be of initial service.

   as an example [ this one is current ],
     have any of you ever tried to teach yourself m4(1),
     with only the "man" page available ?

   i wanted a general_purpose macro_instruction processor.
   on faith, i assumed that "m4" wouldn't be included, if it wasn't useful.
   further, i assumed that it was a "current" tool, because,
     if "m4" was a "legacy" tool, another tool, "for new designs", would exist.
   i had never before been able to make "m4" work "right",
     but, this time, considering the above reasoning,
     i decided to stick with it for more than a few hours
     [ now, i know why:  i am line_oriented ].
   having some initial success, i kept at it, grumbling frequently
     [ if it hadn't been for the "-dV" option,
         i would, probably, have given_up --very-- early on;
         the quoting approach is --not-- intuitively obvious
     ].

   i went three full weeks before i discovered that
     the "info" doc is in "/usr/local", not "/usr/share",
     where i had found the "cc" and "as" "info" docs.
   "make" was with it [ surprise ! ].
   shouldn't those all be in one place ?
   to make things worse,
     the "man" page and the "info" doc assume --opposite-- defaults.
   further, the "info" doc describes feat^H^H^H^Hcharacteristics
     which, in fact, do not exist
     [ perhaps, stallman recruited that author from a redmond marketing firm ].
   after several more weeks of hacking,
     i have, for the most part, figured_out what does work and what does not work.
   i have even developed techniques to
     insert nearly arbitrary white_space into my macroes,
     rendering them amazingly readable.
   this past monday, i installed sendmail [ the latest one; 8_14_3, i think ],
     so that i can see examples of actual use.
   i haven't needed to translate between looping and tail_recursion
     since my fortran days.

   i realize that this is a "gnu" product, so, i put the blame there.
   however, it illustrates my point.

   but, i digress.
]

sorry to go on at such length.
perhaps, if i were to post more frequently, my posts would be shorter.
when i started this, i thought i would type only about one paragraph,
   asking the "roll our own" question.

for ready reference, i enclose the relevant portions of mr. fromme's post.

rob spellberg



Oliver Fromme wrote:
> Matt Olander wrote:
>  > james michael wrote:

[ snip ]

>  > > ... but I don't  
>  > > think the problem is that people aren't willing to do the work, its  
>  > > that places like adobe has closed its software so that we can't  
>  > > really create anything.
>  > 
>  > Actually, Flash9 on FreeBSD 7.x is working pretty good now with Linux  
>  > emulation.
> 
> Unfortunately only with Firefox, and it's far from perfect.
> 
> I tried to get Flash9 working the past few days with the
> latest RELENG_7 and the latest ports.  This is on a UP
> i386 machine, so nothing special.
> 
>  - Native Opera:  No go.  It segfaults.
> 
>  - Linux Opera:  Works somewhat, but hangs often, leaves
>    lots of dead processes behind.  Generally unusable.
> 
>  - Native Firefox3:  Works most of the time.  Problems
>    with youtube (hangs quite often).  Most other sites
>    seem to work better.
> 
>  - Linux Firefox:  Didn't try because the port is marked
>    "forbidden" due to security issues.
> 
> I definitely prefer Opera for normal browsing because it's
> faster and has more useful features, so I use it most of
> the time.  I only start up Firefox when I need to visit
> a site that requires Flash, which doesn't happen too
> often, fortunately.
> 
> Certainly, I wouldn't mind if someone improved the existing
> nspluginwrapper to work better with native Opera, or write
> a new software from scratch that enables using Flash with
> native Opera.

[ snip ]

> Best regards
>    Oliver