Fine Offset + Linux Mint

[Hunter362]

Question, in Cumulus 1 you have the option to copy the files to the web directory rather than ftping them, I want to run this on the same machine
thats hosting my website, I don't see that copy option in CMX

It's exactly the same in MX, you put a file name in the 'remote' box and don't tick 'ftp'. Where is the option that you think is missing?

Ok, just looked to be sure, it was the copy image files to folder, that you could check off. That's what I was remembering.
I did what you said about not 'ticking' the ftp box and that works, what I was wondering about the standard files that are created.

Everything is running on the same machine:
ie: Cumulus is running in /usr/local/sbin/CumulusMX files are created in the /web dir
pages are served from /var/www/html/weather/cumulusmx thus ftping to 'localhost' to 'upload' them to a different directory, rather than either coping them or creating them in that directory in the 1st place.

Am I being backwards in my thinking like this?

[steve]

Ok, just looked to be sure, it was the copy image files to folder, that you could check off. That's what I was remembering.

MX doesn't create any images, so it doesn't have that option.

I did what you said about not 'ticking' the ftp box and that works, what I was wondering about the standard files that are created.

You have to list the standard files as extra files to get them copied, the same as with Cumulus 1. A future enhancement may be to have a single setting to copy the standard files to a specified folder.

[Hunter362]

Ok, just looked to be sure, it was the copy image files to folder, that you could check off. That's what I was remembering.

MX doesn't create any images, so it doesn't have that option.

I did what you said about not 'ticking' the ftp box and that works, what I was wondering about the standard files that are created.

You have to list the standard files as extra files to get them copied, the same as with Cumulus 1. A future enhancement may be to have a single setting to copy the standard files to a specified folder.

Ahh got it, not a big deal at all just thought I was missing something there. The copy image files box is what I remembered from the settings in Cumulus 1
I was thinking about just setting a cron job to do it every min, but looked and the *.json files must be created on the fly... no?

Love it so far, just glad that you took the time to rewrite it to run on the different platforms now.

Quick side note, I have it set to use Cumulus Forecast, update hourly, since starting the program last night and with Baro going up my forecast hasn't changed at all has read: ,Stormy ,much rain
since I started it last night.

http://weather.cerchia.com/index.htm Cumulus-1
http://weather.cerchia.com/cumulusmx CumulusMX

[steve]

I was thinking about just setting a cron job to do it every min, but looked and the *.json files must be created on the fly... no?

The json graph data files are created at the same time as the standard files. If you're not using ftp, don't specify an ftp server and it will (should) just create the files, and you can then copy them to wherever using the extra files list.

Quick side note, I have it set to use Cumulus Forecast, update hourly, since starting the program last night and with Baro going up my forecast hasn't changed at all has read: ,Stormy ,much rain
since I started it last night.

This could be a bug in the handling of the 'extremes' for different units. Can you check that your extremes are set correctly, and the corresponding unit is selected for the extremes that are specified?

[Hunter362]

I was thinking about just setting a cron job to do it every min, but looked and the *.json files must be created on the fly... no?

The json graph data files are created at the same time as the standard files. If you're not using ftp, don't specify an ftp server and it will (should) just create the files, and you can then copy them to wherever using the extra files list.

Quick side note, I have it set to use Cumulus Forecast, update hourly, since starting the program last night and with Baro going up my forecast hasn't changed at all has read: ,Stormy ,much rain
since I started it last night.

This could be a bug in the handling of the 'extremes' for different units. Can you check that your extremes are set correctly, and the corresponding unit is selected for the extremes that are specified?

Just changed the extremes to what I have set in Cumulus-1, I had left the default's set for what would be for mb/hPa
when I'm using inHg
Restarted CMX and it's happy now! Thank you!

[Buford T. Justice]

In Ubuntu and it's derivatives for 14.04 Trusty Tahr, in both /lib/x86_64-linux-gnu and /lib/i386-linux-gnu there is a link file called libudev.so.1 which links to libudev.so.1.3.5. I decided the hell with it and made another link file in both locations called libudev.so.0 by right-clicking on libudev.so.1.3.5, making a link, and then renaming the link file. I fired up CMX and data is being displayed. IT'S ALIVE!!!

cd /lib/x86_64-linux-gnu/
sudo ln -sf libudev.so.1 libudev.so.0

I did read somewhere in my Googling on this when it first came up that libudev0 and libudev1 are not the same beast (hence the different names ) and whilst creating a cross link may work for some things, it may break others, and is generally considered a bad idea.

I just did a Ubuntu MATE 14.04.2 LTS reinstall, installed Cumulus MX, and it will not find the Fine Offset unless you do the link. Why does Cumulus MX use the older libudev.so.0 file instead of the new libudev.so.1 file?

[steve]

Why does Cumulus MX use the older libudev.so.0 file instead of the new libudev.so.1 file?

The cross-platform USB HID library used by MX uses it.

[Buford T. Justice]

The cross-platform USB HID library used by MX uses it.

I've been sitting here reading different Linux forums about this and they mostly say linking is fine as, if problems do occur, the link can be deleted. Not trying to sound mean or anything, but wouldn't it be better if Cumulus MX supported the newer file instead of the older one that is pretty hard to get?

[steve]

Not trying to sound mean or anything, but wouldn't it be better if Cumulus MX supported the newer file instead of the older one that is pretty hard to get?

Read what I wrote. The cross-platform USB HID library used by MX uses it. Not my code.

Wouldn't it be better if Ubuntu didn't screw developers by stopping providing a library which is used by lots of existing code, instead forcing them to modify their code?

[Buford T. Justice]

Read what I wrote. The cross-platform USB HID library used by MX uses it. Not my code.

Wouldn't it be better if Ubuntu didn't screw developers by stopping providing a library which is used by lots of existing code, instead forcing them to modify their code?

I did read what you wrote and I suppose so, but it sounds more like developers have no choice. They have to change with the times. Just like Windows XP doesn't support .NET 4.5, Ubuntu and many distros based on Ubuntu (craploads) no longer support libudev.so.0. The only Ubuntu distros which come with libudev.so.0 that are still currently updated are those based on 12.04 LTS and support is going to end April 2017. Even Fedora 20 comes with a libudev.so.1 link which links to libudev.so.1.4.0 without a libudev.so.0 link. I just checked this with a Fedora 20 Live CD.

According to this, creating the link can lead to silent data corruption...

http://askubuntu.com/questions/369310/h ... tart-again

But still we know that creating a link called libudev.so.0 to libudev.so.1.3.5 allows Cumulus MX to work on an Ubuntu Linux system. So why can't the libudev.so.1 link that is already there not be used? Now I am reading what you said. So the library cannot be updated to use libudev.so.1 instead of libudev.so.0? A 0 cannot be changed to a 1? There is not a newer version of this USB library which has already made this change?

In order to not have other possible problems arise from doing this unadvised link, the user is suppose to run an older Linux version that comes with libudev.so.0?

[steve]

I don't know whether the library can be changed to use libudev.so.1, it's a free library and the developer hasn't updated it, which is up to him. As with Cumulus, he wrote it for himself, and has kindly made it available for others to use. It does what he wants it to do. Without it, there would be no Cumulus MX.

A 0 cannot be changed to a 1?

Hilarious. This is like the comments that I get from time to time (including one just this week) that changing Cumulus to do something "would be trivial". Always from people who start with "I am not a programmer..."

It appears that there is no libudev.so.1 for Raspbian, so even if the library were to be updated, it would break it for Raspberry Pi users of MX.

[Buford T. Justice]

Making a link called libudev.so.0 is essentially changing a 1 to a 0. The actual file, libudev.so.1.3.5, works fine with the library. But the idea of silent data corruption is worrisome.

[steve]

If, as you appear to be suggesting, the only required change to the library were to change a '0' to a '1', the end result would be exactly as you have now, with the symbolic link. Perhaps that is the only change that would be required, perhaps not. I don't know because I'm not a Linux systems programmer, and I don't presume to tell other programmers what is and what isn't a trivial change (there are actually no completely trivial, risk-free changes to most software anyway). Neither do I presume to tell providers of free software that they have to "change with the times". Your argument comparing the XP and .Net 4.5 situation with the latest Ubuntu distributions and libudev.so.0 is ass-backwards. XP hasn't changed, it is obsolete and no longer supported. The latest version of Ubuntu has broken a lot of software by consciously making a breaking change. No-one is being forced to use the latest version, and apparently there is a currently supported version which will continue to be supported for the next two years and which isn't broken by not having libudev.so.0.

The point remains that the Raspberry Pi (users of which constitute the vast majority of Cumulus MX users) currently has no libdev.so.1. So if the symbolic link works, you will have to continue to use it, sorry. I can't imagine the risk of data corruption is significant compared to the normal operation of a Fine Offset station anyway.

[Buford T. Justice]

There isn't anything ass-backwards about the XP argument. What is going to happen when Ubuntu 12.04 LTS loses its support in a couple of years? It and libudev.so.0 will be as dead as Windows XP and Julius Caesar. And it is not just Ubuntu. Fedora is not even doing libudev.so.0 either. I tested that on Fedora 20 and the current version is Fedora 22. The point is all Linux distros are getting away from libudev.so.0 in favor of libudev.so.1. I am not asking for a feature request like having MySQL support or pretty graphs or whatever. It is a security request as there are warnings that creating the libudev.so.0 link can be bad, but unfortunately it is the only way to make Cumulus MX and that outdated USB library work with a current version of Linux. I am downloading Raspian Wheezy which was updated on 5/5 to see if it is using libudev.so.0 or libudev.so.1 assuming the download works like a Live CD. I see there are links to other third-party OSes for the Raspberry with Ubuntu at the top of the list...

https://www.raspberrypi.org/downloads/

This is a beta test forum right? As a good beta tester, I am trying to politely tell you there is a problem worth at least looking at.

[steve]

I understand perfectly well that there is an issue. Please tell me what I can do about it.