$whoname
Greg's mail about wview
Greg's diary
Photo index
Greg's home page
Network link stats
Greg's other links
Copyright information
Groogle

This is a mail exchange I had with Mark Teel on 21 February 2012. See that link for the discussion.

In a former version of this page I invented a gmail address so as not to annoy Mark more than necessary. Unfortunately, the address exists, so I annoyed an innocent bystander instead. My apologies to him. Clearly I'm not going to state his name.

From Mark Teel, Mon, 20 Feb 2012 15:27:34 -0800

From Greg Lehey, Tue Feb 21 13:02:44 2012 +1100

From Mark Teel, Mon, 20 Feb 2012 22:55:05 -0600

Date: Mon, 20 Feb 2012 17:27:32 -0600
From: Mark Teel <notarealaddress@example.com>
Subject: Your Emetic Commentary

Almost every remark in your WH1080 blog concerning wview is wrong.
Radlib undocumented? Can you google for the home page where an API
reference is found? I guess not.  Version 4 data file format
undocumented? Try reading the wview User Manual which indicated it was
the Weatherlink file format. The wviewweather.com site even has a link
to the file format spec. I don't use IPC messages and as radlib is
intended, it provides an RTOS-like API to unix, thus the need for
semaphores and shared memory.

Apparently you truly are a hacker. You obviously don't like or
understand well-structured applications. I guess it requires a hacker
too much time to actually understand a SW library or utility instead of
the God-awful inline crap I have seen in the linux and freeBSD kernels
in places. But it's all right there in one place to hack, right? And
damn, why would anyone need more than one rambling (probably polling)
thread of execution in one process. The horrors of multiple processes,
data encapsulation and the like.

"Your" weather software is not yours - rather a conglomeration of other
SW. That's fine except when you bitch like a little girl while stealing
ideas.

Finally, your entire attitude about other people's work truly is emetic.
You are either becoming senile (and thus a moron) or you are just a moron.

Mark Teel
wview Author

Next message

Date: Tue, 21 Feb 2012 13:02:44 +1100
From: Greg 'groggy' Lehey <groggyhimself@lemis.com>
To: Mark Teel <notarealaddress@example.com>
Subject: Re: Your Emetic Commentary

On Monday, 20 February 2012 at 17:27:32 -0600, Mark Teel wrote:
> Almost every remark in your WH1080 blog concerning wview is wrong.

I don't have a blog.  Could you give me a URL?  Conceivably it might
mean I have to correct some of the comments below.

> Radlib undocumented? Can you google for the home page where an API
> reference is found? I guess not.

I don't find a reference to the text "API" on
http://www.radlib.teel.ws/

In any case, don't guess.  Read.  What I find in my diary
(http://wwww.lemis.com/grog/diary-sep2009.php#D11-13) is:

   So, what's the problem? One is clearly a badly documented and
   rickety framework (the only documentation I can find for radlib is
   a API reference). The other is the Tower of Babel attitude to
   software design.

> Version 4 data file format undocumented? Try reading the wview User
> Manual which indicated it was the Weatherlink file format.

Yes, after checking that, it seems that I missed this one.  Let me
know that URL and I'll fix the comment.

> I don't use IPC messages and as radlib is intended, it provides an
> RTOS-like API to unix, thus the need for semaphores and shared
> memory.

That could be some explanation.

> Apparently you truly are a hacker.

In my circles that's a compliment.  You use it as if it were an
insult.

> You obviously don't like or understand well-structured applications.

On the contrary.  That's why I wrote my own.

> I guess it requires a hacker too much time to actually understand a
> SW library or utility instead of the God-awful inline crap I have
> seen in the linux and freeBSD kernels in places.

Arguably a library that requires research is not a good library.  In
the case of wview it appears to be overkill and part of the reason why
it was so unstable (I don't know if you've fixed that).

> But it's all right there in one place to hack, right?

The kernel?  Have you ever written kernel code?  Ever had it
committed?  Code of the quality I recall from wview would never make
it into the FreeBSD kernel.

> And damn, why would anyone need more than one rambling (probably
> polling) thread of execution in one process. The horrors of multiple
> processes, data encapsulation and the like.

From what I see in my old diaries, wviewd does something like polling:

http://www.lemis.com/grog/diary-sep2009.php#D9-11

  Did some tracing and discovered that it was getting valid input, so
  the EAGAIN was benign beyond the error messages. Ignoring them
  worked, but the wviewd process used something like 35% processor
  time. Put in a little code to delay a bit (10 ms) and retry if it
  hit that error. That works, but it sounds like a bug in the USB
  implementation to return EAGAIN on a blocking read.

Clearly that's in code that's not in the original wviewd, but it
suggests that it's not the program/process structure that eliminates
the need for polling.  On the other hand, I don't see how you can
avoid this.  You need to get data from the device at regular
intervals.

There are many reasons to use multiple processes--mine does too.  But
when one of my processes goes away, you can restart it.  With wview
(and recall, this was an old version) I was continually running into
problems like here (11 September 2009)a:

  Getting things started again wasn't easy. Various components
  wouldn't stop, and starting things manually is greatly hampered by
  the presence of PID files that don't get ignored if the process has
  died.

I think the entry at
http://www.lemis.com/grog/diary-nov2009.php#powercor sums it
up, though:

    kimchi was another matter: I got a continual stream of

    Nov 12 09:59:36 kimchi wviewd[3154]: <1257980376216> : readStationData: preposterous station pressure! 549.099976

    Wunderground and my own weather records showed complete
    nonsense. How do you debug that? I don't even know where this
    information is coming from. I can't debug the wviewd daemon,
    because it's tied up in this horrible startup script with lots of
    dependencies and System V semaphores. I tried stopping and
    restarting wview a few times, but it didn't help. Tried renaming
    the archive files—they've proven to cause problems in the past—but
    that didn't help either.

This inability to debug is a real pain.  How do *you* debug the
software?

    This is ridiculous. What this daemon should be doing is simply
    reading the data from the device at specified intervals and
    storing the data in a database, and that can be debugged
    easily. Clearly a bit of error checking is a good idea (that's
    what these messages are about, after all), but the complexity of
    the code is mind-boggling.

    One thing, though, that seems to justify the decision to write my
    own transfer daemon: the information returned by the station is in
    metric units, sort of. The wind speed, for example, is in units of
    0.1 m/s. wview translates everything into American units first,
    and if you select metric units it translates them back again. In
    the process it loses a lot of accuracy. 0.1 m/s is 0.36 km/h;
    wview stores in units of 1 mph (1.6 km/h), and that's what my
    records show.

In other words, independently of the issues you raise, the file format
was inappropriate both for the device and for people living in the
Real World.  Based on abrasive replies I had already had from you, I
didn't consider it a viable option to suggest an improvement.  Your
current message confirms this.

> "Your" weather software is not yours - rather a conglomeration of
> other SW.

You've checked it, have you?  Of course my weather software bases on
information others have gleaned about the WH 1080, notably the code
that Steve Woodford sent me, and also some information on libusb that
Hugh Blemings sent to me.  But I didn't use this code except to
understand the protocol, in the process discovering that the code
contained lots of incorrect parameters and redundant calls to libusb.
The code is 100% new.

> That's fine except when you bitch like a little girl while stealing
> ideas.

Can you give an example, preferably explaining what the difference is
between bitching the way you do it and the way a little girl does it?

> Finally, your entire attitude about other people's work truly is
> emetic.  You are either becoming senile (and thus a moron) or you
> are just a moron.

I like the use of the word "emetic".  It's one of my favourites.  Have
you used it before, or did you "steal" it?  The only hits I find for
https://www.google.com/search?q=%22mark+teel%22++emetic&btnG=Groogle+Search
are on my web site.

In any case, if you reply, I shall do so too.  But in fairness I
should say that this message has only served to confirm the
correctness of my decision to dump wview.  My software has caused me
almost no problems over more than two years, far less than I had with
wview over 2 months.  It's also much smaller.  And then there's the
personal issue: I've met with a number of unsavoury people over the
years, but you must come close to the top.

Greg
--
Sent from my desktop computer
Finger groggyhimself@FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua

Next message

Date: Mon, 20 Feb 2012 22:55:05 -0600
From: Mark Teel <notarealaddress@example.com>
To: Greg 'groggy' Lehey <groggyhimself@lemis.com>
Subject: Re: Your Emetic Commentary

On 2/20/12 8:02 PM, Greg 'groggy' Lehey wrote:
> On Monday, 20 February 2012 at 17:27:32 -0600, Mark Teel wrote:
>> Almost every remark in your WH1080 blog concerning wview is wrong.
> I don't have a blog.  Could you give me a URL?  Conceivably it might
> mean I have to correct some of the comments below.
You knew what I meant. A diary?
>
>> Radlib undocumented? Can you google for the home page where an API
>> reference is found? I guess not.
> I don't find a reference to the text "API" on
> http://www.radlib.teel.ws/
Why must it be text?
>
> In any case, don't guess.  Read.
I'm know you didn't read the wview User Manual before making your
comments. Hypocrite.
> What I find in my diary
> (http://wwww.lemis.com/grog/diary-sep2009.php#D11-13) is:
>
>     So, what's the problem? One is clearly a badly documented and
>     rickety framework (the only documentation I can find for radlib
>     is a API reference). The other is the Tower of Babel attitude to
>     software design.
Or the "I know everything because I wrote kernel code" attitude. I have
in fact hacked some kernel code, as it lends itself to hacking (written
by other "make it work" slouches).
>
>> Version 4 data file format undocumented? Try reading the wview User
>> Manual which indicated it was the Weatherlink file format.
> Yes, after checking that, it seems that I missed this one.  Let me
> know that URL and I'll fix the comment.
>
>> I don't use IPC messages and as radlib is intended, it provides an
>> RTOS-like API to unix, thus the need for semaphores and shared
>> memory.
> That could be some explanation.
>
>> Apparently you truly are a hacker.
> In my circles that's a compliment.  You use it as if it were an
> insult.
And it is. Plinking with someone's creation, trying shit until it works,
throwing stuff up against a wall until it sticks. It's not engineering
in the least.
>
>> You obviously don't like or understand well-structured applications.
> On the contrary.  That's why I wrote my own.
And it is so good it isn't even open source. Afraid of scrutiny yourself?
>
>> I guess it requires a hacker too much time to actually understand a
>> SW library or utility instead of the God-awful inline crap I have
>> seen in the linux and freeBSD kernels in places.
> Arguably a library that requires research is not a good library.
That is a stupid statement. No sane engineer would make such an
argument. Did you just "know" how to use libusb with all those poorly
named functions?
>    In
> the case of wview it appears to be overkill and part of the reason why
> it was so unstable (I don't know if you've fixed that).
The only thing unstable was your brutish attempt to understand it. There
are users running on embedded devices and servers with > 1 year up time.
radlib has been used in commercial and classified applications. Wrong again.
>
>> But it's all right there in one place to hack, right?
> The kernel?  Have you ever written kernel code?  Ever had it
> committed?  Code of the quality I recall from wview would never make
> it into the FreeBSD kernel.
I have for commercial purposes, both linux and FreeBSD. Not that big of
a deal pal.
>
>> And damn, why would anyone need more than one rambling (probably
>> polling) thread of execution in one process. The horrors of multiple
>> processes, data encapsulation and the like.
>  From what I see in my old diaries, wviewd does something like polling:
>
> http://www.lemis.com/grog/diary-sep2009.php?topics=c#D9-11
>
>    Did some tracing and discovered that it was getting valid input, so
>    the EAGAIN was benign beyond the error messages. Ignoring them
>    worked, but the wviewd process used something like 35% processor
>    time. Put in a little code to delay a bit (10 ms) and retry if it
>    hit that error. That works, but it sounds like a bug in the USB
>    implementation to return EAGAIN on a blocking read.
>
> Clearly that's in code that's not in the original wviewd, but it
> suggests that it's not the program/process structure that eliminates
> the need for polling.  On the other hand, I don't see how you can
> avoid this.  You need to get data from the device at regular
> intervals.
This doesn't require polling, or have you ever used timers?
>
> There are many reasons to use multiple processes--mine does too.  But
> when one of my processes goes away, you can restart it.  With wview
> (and recall, this was an old version) I was continually running into
> problems like here (11 September 2009)a:
>
>    Getting things started again wasn't easy. Various components
>    wouldn't stop, and starting things manually is greatly hampered by
>    the presence of PID files that don't get ignored if the process has
>    died.
>
> I think the entry at
> http://www.lemis.com/grog/diary-nov2009.php?topics=c#powercor sums it
> up, though:
>
>      kimchi was another matter: I got a continual stream of
>
>      Nov 12 09:59:36 kimchi wviewd[3154]:<1257980376216>  : readStationData: preposterous station pressure! 549.099976
>
>      Wunderground and my own weather records showed complete
>      nonsense. How do you debug that? I don't even know where this
>      information is coming from. I can't debug the wviewd daemon,
>      because it's tied up in this horrible startup script with lots of
>      dependencies and System V semaphores. I tried stopping and
>      restarting wview a few times, but it didn't help. Tried renaming
>      the archive files—they've proven to cause problems in the past—but
>      that didn't help either.
>
> This inability to debug is a real pain.  How do *you* debug the
> software?
Kernel development, really, asking that question? wview startup scripts
now have the option to run in the foreground and be traced. But that
should have been common knowledge to a kernel developer. I don't require
much source-level debugging because of the sound software design and
data encapsulation. I am not a slave to design by debugger. Horrible
startup script? Wow! System V semaphores are horrible? How do you
achieve process synchronization? Wow again, it's like talking to a
college freshman.
>
>      This is ridiculous. What this daemon should be doing is simply
>      reading the data from the device at specified intervals and
>      storing the data in a database, and that can be debugged
>      easily. Clearly a bit of error checking is a good idea (that's
>      what these messages are about, after all), but the complexity of
>      the code is mind-boggling.
Complexity? Or your simplicity of mind?
>
>      One thing, though, that seems to justify the decision to write my
>      own transfer daemon: the information returned by the station is in
>      metric units, sort of. The wind speed, for example, is in units of
>      0.1 m/s. wview translates everything into American units first,
>      and if you select metric units it translates them back again. In
>      the process it loses a lot of accuracy. 0.1 m/s is 0.36 km/h;
>      wview stores in units of 1 mph (1.6 km/h), and that's what my
>      records show.
>
> In other words, independently of the issues you raise, the file format
> was inappropriate both for the device and for people living in the
> Real World.
Because no tenths of m/s for wind speed? From a WH1080 clone? Misguided
righteousness. Your station is much less accurate than that.
>    Based on abrasive replies I had already had from you, I
> didn't consider it a viable option to suggest an improvement.  Your
> current message confirms this.
I imagine your questions were as abrasive based on your remarks in your
"diary".
>
>> "Your" weather software is not yours - rather a conglomeration of
>> other SW.
> You've checked it, have you?  Of course my weather software bases on
> information others have gleaned about the WH 1080, notably the code
> that Steve Woodford sent me, and also some information on libusb that
> Hugh Blemings sent to me.  But I didn't use this code except to
> understand the protocol, in the process discovering that the code
> contained lots of incorrect parameters and redundant calls to libusb.
> The code is 100% new.
>
>> That's fine except when you bitch like a little girl while stealing
>> ideas.
> Can you give an example, preferably explaining what the difference is
> between bitching the way you do it and the way a little girl does it?
i am not borrowing or otherwise using any source code of yours, code you
spent many hours on. You, on the other hand, have this horribly
misguided view that you know something about SW engineering, when in
fact you refer to a layered design as "tower of babel". You did spend
enough time on wview source to write some foolish and some harsh remarks
in your diary. That's the difference. This is me calling you out on your
whining and your unjustified self importance.
>
>> Finally, your entire attitude about other people's work truly is
>> emetic.  You are either becoming senile (and thus a moron) or you
>> are just a moron.
> I like the use of the word "emetic".  It's one of my favourites.  Have
> you used it before, or did you "steal" it?
I was disgusted by it in one of your posts or the foolish pdf you
produced. I imagine it is one of your favorites. It is a vile word.
>   The only hits I find for
> https://www.google.com/search?q=%22mark+teel%22++emetic&btnG=Groogle+Search
> are on my web site.
>
> In any case, if you reply, I shall do so too.  But in fairness I
> should say that this message has only served to confirm the
> correctness of my decision to dump wview.  My software has caused me
> almost no problems over more than two years, far less than I had with
> wview over 2 months.
The fact it took you two months to fail at understanding wview when
others of better engineering pedigree pick it up in two hours (and like
it) says all I need to say.
>   It's also much smaller.  And then there's the
> personal issue: I've met with a number of unsavoury people over the
> years, but you must come close to the top.
And your diary is all kittens and puppies? You dish out incorrect and
venomous crap but can't take the truth, albeit venomous too.

Good luck to you. If you ever make your code public I will be the first
to write a review of it.
>
> Greg
> --
> Sent from my desktop computer
> Finger groggyhimself@FreeBSD.org for PGP public key.
> See complete headers for address and phone numbers.
> This message is digitally signed.  If your Microsoft MUA reports
> problems, please read http://tinyurl.com/broken-mua

Greg's home page Greg's diary Greg's photos Copyright

Valid XHTML 1.0!

$Id: mail.php,v 1.1 2015/08/23 00:24:48 grog Exp $