What could go wrong?

Mon Jun 29 13:20:50 EDT 2020

First of all, I am an equal opportunity OS hater.  I don’t support them professionally, but I DO often push them with my experimenting and heavy usage.

I have not had Pete’s experience with Windows 10.  I regularly run my Flex 6500 for days and days without rebooting the Win box.  But, I don’t usually multitask that box.  It runs the ham station only.

I have had SO MANY problems with Linux over the years, that my email tag line is: “Linux has been deprecated from here”.  Not quite true, but mostly is.  Throughout my time with Linux I have had so many problems with drivers changing, libraries moving around, and things being “deprecated” that I prefer NOT running Linux.  Mel keeps telling me that I’m a rare user that pushes the envelope, but I am what I am.

For example, a while back I tried to update an early SDR project (my own SDR101) that used QT, eclipse, and something else.  Well, I quickly found that Ii t no longer compiled, with tons of errors.  Turns out that Eclipse and the “other” software it relied on had library locations change, and everything was broken.  Note that this wasn’t a problem with MY code, but the supporting compiling stuff.  I gave up trying to fix it after several days.  Too much time wasted falling down the rabbit hole.

Another Linux example is GNU Radio.  Again, several years ago, I wrote a bunch of GNU Radio projects for AM, FM, SSB, and other SDR projects, to use with SoftRocks and the Charleston SDR.  A couple of years ago, I tried to use them again with the Charleston SDR.  Lo and behold, almost EVERY SINGLE module within GNU Radio had changed name and calling, my code called functions that were “deprecated”.  WHY?  I’m not talking about problems with my code, but the simple modules that come with GNU Radio.  Again, it would take so to fix it that I just went to another project.  Most other support code allows backward compatibility, but apparently not in the Linux world.

Linux use has drastically dropped here, partially due to the above.  It’s not really the “Linux” OS itself, rather the various distros that the wizards keep changing.  My time is valuable, so spending time to fix what they broke is just wasted overhead.  I can run Windows programs from many years ago, not so with what I’ve tried with Linux.  I’d rather play in the occasional world of DLL Hell than the constantly deprecated Linux world.

And, don’t get me started on Apple.  I tried that, got the t shirt, coffee mug, and years of Apple Store bills just to make any software available to the general public.

Anyway, back to my IMSAI running CP/M....
73, Terry, N4TLF

From: Howard F. Cunningham 
Sent: Monday, June 29, 2020 11:14 AM
To: kf4hcw ; tacos at amrad.org 
Subject: RE: What could go wrong?

Hi See my comments below

Howard Cunningham, MCP

howardc at macrollc.com - personal

For technical support, send an email to service at macrollc.com or call 703-359-9211 (24/7)

From: kf4hcw [mailto:kf4hcw at lifeatwarp9.com] 
Sent: Monday, June 29, 2020 10:20 AM
To: Howard F. Cunningham; tacos at amrad.org
Subject: Re: What could go wrong?

On 6/29/20 9:54 AM, Howard F. Cunningham wrote:

  Today’s Windows rarely needs to be rebooted, if only Windows is running.  What you are running into is a program that is not playing nice and creating problems.

I beg to differ -- I am in the position to directly and indirectly support many systems on many different platforms and of all of them Windows is the most misbehaved. As for requiring the restart -- this is my direct experience. If left to run for more than about 30 hours, clock jitter creeps into the system and the scheduler no longer keeps pace with the data up and down with the flex6300 -- this causes missed samples which amount to wideband noise in the channel. The only mitigation that has been successful is the reboot. (I tried everything except for running dedicated hardware).

[HC:>] When you say clock jitter I think that you are saying that the clock drifts, probably slower, over time.  This tells me that the system is busy and missing the clock timings.  When Windows starts, it checks the BIOS clock for its time.  While running Windows does not check the BIOS clock but rather updates a counter which is used for the time.  I wonder if telling Windows to use a ntp server would solve this problem.

As for "Today's Windows" - For some things win 7 pro is still required (due to driver and other support issues) and in any case Win10 is just as nightmarish and unstable if not worse... again, direct experience, not a myth.

[HC:>] That is not our experience with Windows 7 and Windows 10.  We have found Windows 10 to be more stable than Windows 7.

I work with systems that almost never need to be restarted most of the time -- all of the win* boxen I must manage frequently have these and other issues when compared with my lin* boxen. It's not a myth, it's an inescapable burden I fight every day.

[HC:>] I never said that Windows was more stable than Linux.

It's my experience that most folks are so used to rebooting Windows on a regular basis that they don't even notice they are doing it. As a result they don't run into some of these issues simply because as a matter of course they regularly reboot for all sorts of reasons (often enough not even their choice).

[HC:>] My clients do not routinely reboot their computers.  What usually happens is that the systems are rebooted as part of the monthly patch process.  That most likely prevents us from seeing the need to reboot random Windows 10.

Trying to support long-running timing critical software on Windows is problematic and requires special care -- that's all I'm saying. I didn't make it up.

[HC:>]  I never said that Windows never needs rebooting and I did not say that there are never problems on some Windows systems.  The problem has very muchly improved today.  What I should have said is that Windows should not need to be rebooted daily or even weekly.  Where we see this problem we are able to track the need to reboot down to a specific program that causing the problem.

  A thought on the unlimited amount of data..  You could try running a scheduled task to delete the data.  Keep in mind that I do not know if this data is needed or what happens if the data is deleted while wispr is running.  If wispr needs that data while running, you could try using a scheduled task to shutdown wispr, delete the files, and restart wispr (assuming that wispr does not require any keyboard interaction to start)

I don't think it's required by wspr -- wspr is simply generating the data as some kind of log... given the unmitigatable bloat of win* 40G of disk space is not enough after a few days and wspr will generate enough data to fill up the remaining space; but since I have to reboot it in order to avoid the timing problems it's a) not a problem to delete the data (there is indeed a menu option for it in the program) and b) a scheduled task would not run reliably because of the necessary reboot.

[HC:>] We use a tool that allows to schedule things like deleting files like this.  We have also used it to reset the clock on a couple of systems that has clock drift.  That was years ago.

It's not as terrible as it seems -- one should check in on these kinds of systems periodically as a matter of course anyway; so handling the required reboot and reset as part of that maintenance is easy enough to fit in.

[HC:>] We do monitor all of our client systems to hopefully catch problems before the client sees them.

_M

-- kf4hcwPete McNeillifeatwarp9.com/kf4hcw

--------------------------------------------------------------------------------
_______________________________________________
Tacos mailing list
Tacos at amrad.org
https://lists.amrad.org/mailman/listinfo/tacos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.amrad.org/pipermail/tacos/attachments/20200629/ad80280a/attachment.html>