Greg's mail about wview

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

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