Subject: Re: [44net] 44.151.29.29/32 F4LTS From: "Marc, LX1DUC" lx1duc@laru.lu Date: 02/25/2015 08:25 PM
To: 44net@hamradio.ucsd.edu
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I would be happy to scrap the Portal and go back to the procmail scripts that Jim Fuller developed and operated for decades. Things worked, and worked dependably, back then!!
The Portal is way too "vaccuumous" for me:(
--- Jay WB8TKL
Hello Jay,
I assume that like any development project, Jim's solution didn't work 100% from the beginning either. Cut the developers of the portal some slack and report your issues here, so the issues become known and can be fixed (or someone may provide a workaround).
Anyway the thanks to all the developers on the project!
73 de Marc
I agree with that in principle, but I have reported several issues and rarely ever was anything changed to solve those issues, while in the meantime things were changed that caused even more issues (like the mandatory selection of a registered subnet for an IPIP tunnel), or that added features that were not near the top of any wishlist observed here (like an API).
What I need in my daily work as a coordinator in a network that has been springing into life again is a usable mechanism for address assignment, and a way to edit an existing structure into the new database. Without those present, I have to work around the system and tell people to ignore features and make requests in a separate mail.
That would be fine if there would be visible progress, say a new feature every month or two, but I have a hard time seeing any.
Rob
Anyway the thanks to all the developers on the project!
73 de Marc
I agree with that in principle, but I have reported several issues and rarely ever was anything changed to solve those issues,
1. If you find a bug please let me know and I will do my best to fix it ASAP.
2. If you want a new feature it goes to the bottom of my TODO list.
3. My TODO list doesn't seem to get any shorter!
4. I used to be semi-retired and had plenty of time to work on unpaid projects like this, unfortunately life intervened, as it often does, and I'm now back working full time, so spare time is somewhat limited currently. I am expecting that to change in a couple of months as the commercial project I've been working on for the past 12 months is nearing an end.
5. I have asked for help with programming, translations, documentation, etc. So far the only person to actually do anything has been Tom - SP2L who very kindly provided the Polish translation. If you want things to progress it really should be a group effort.
</rant>
Thanks :-)
Chris G1FEF
On Thu, Feb 26, 2015 at 12:16 AM, G1FEF chris@g1fef.co.uk wrote:
- I have asked for help with programming, translations, documentation, etc. So far the only person to actually do anything has been Tom - SP2L who very kindly provided the Polish translation. If you want things to progress it really should be a group effort.
I think if you were to open source the portal you would get more volunteers. I, and many other open source developers, tend to wait to jump in to a new project until we have an itch that needs scratching. When a bug affects me, I'll look to the source to see if I can squash it. If I can, the project maintainer can expect a patch from me. If the source isn't public, I'll send a bug report to the developer. I presume you would prefer patches to bug reports.
(It's my understanding that the portal code is kept in a private SVN repository. If it's actually public, please ignore this rant and simply reply with the URL.)
Tom KD7LXL
On Thu, 26 Feb 2015, Tom Hayward wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Thu, Feb 26, 2015 at 12:16 AM, G1FEF chris@g1fef.co.uk wrote:
- I have asked for help with programming, translations, documentation,
etc. So far the only person to actually do anything has been Tom - SP2L who very kindly provided the Polish translation. If you want things to progress it really should be a group effort.
Yes!
I think if you were to open source the portal you would get more volunteers. I, and many other open source developers, tend to wait to jump in to a new project until we have an itch that needs scratching. When a bug affects me, I'll look to the source to see if I can squash it. If I can, the project maintainer can expect a patch from me. If the source isn't public, I'll send a bug report to the developer. I presume you would prefer patches to bug reports.
Everyone has rightful ownership to the programs they write, and naturally no-one can be forced to make his project open source, but I believe being open source would be beneficial for the portal & other infrastructure components of amprnet. I'll try to make a point in favor of that.
I'd like to highlight that Tom is not just ranting there, he's really, actually doing what he's saying he's doing. Here's an example from another amateur radio service.
The aprs2.net service consists of roughly 90 APRS-IS servers, which provide APRS service to the vast majority of the APRS users (5000-6000 clients connected). The servers are run by a bunch of sysops, much like the amprnet gateways (there's probably some overlap within the set of sysops).
The aprs2.net servers need to be on the DNS, each server has a hostname like 'finland.aprs2.net' or 'tokyo.aprs2.net'. There are also round-robin hostnames such as 'rotate.aprs2.net' which points to an ever-changing set of servers which are currently working, and currently have less users than the other working servers. End users put the rotates in their config files, and should always get to a working server.
The aprs2.net servers have a sysop portal, which is conceptually very much like the one Chris has made for the amprnet. Sysops use it to enter and change details (like IP addresses) of the servers. Tom made that portal, in Python, on top of the popular Django framework. The source code is here for everyone to see, improve and reuse: https://github.com/kd7lxl/aprs2netportal
I made the backend code (https://github.com/hessu/aprs2net-backend) which downloads a server list from the portal, tests the servers (testing from 3 servers on 3 continents), and updates the DNS every few minutes as necessary, and provides a status page: http://status.aprs2.net/ - you can also look at individual pollers / testers, http://t2poll-us.aprs2.net/ is the one in the US. Click on table header column "Tested" to sort and see the real-time updates.
If you want to improve it, you can just download the source code right away, and start doing it, without asking Tom or me. If you want your improvements to go to use, you can make a pull request. If you get tired or don't have the time to finish your improvements after all, you can just stop, no-one will need to know or be bothered about your laziness. These are actually grand features, they greatly lower the barrier to just go and try to make a little change, even if you're really busy and you're not sure if you'll be able to finish it, or if you're not so sure about your programming skills.
Also, when Tom at some point is busy with his life or otherwise finds something more interesting to do, the portal's source code is there, a bunch of people have a copy of it, and we can happily continue developing it from where he left, instead of starting from scratch. It's OK, people move on with life, get old, have kids, get sick from time to time. That's just life.
...
This week I've been at home, with a nice little flu. On Tuesday I got bored, and wanted to play with radio a bit. Namely, I wanted to try full duplex using my two hackrf SDR radios. Turned out it didn't work - the drivers and the firmware did not support more than 1 of these half duplex USB radios to be connected at a time, although it had been said that it would be possible to do just that. With a bit of googling I found out that Jared Boone had already written most of the important code that was needed to do it, but it was "hacky" and not ready for release. He had published his unfinished work anyway in May 2014, hidden in a branch on github, with a documented set of Things That Need To Be Done before Release:
https://github.com/mossmann/hackrf/commit/3c1c49f7bf36b7
I had no idea whether it would work, and whether I could get those done, whether it would simply be a bit too difficult. But with a day to spare, I tried, item by item. Turns out it wasn't that hard, took just 1 evening, and a bit of additional time the next morning. Mike Ossman will test and review my additional changes (https://github.com/mossmann/hackrf/pull/158) and soon multi-device support could be in the main hackrf driver & firmware for everyone to use. If I had failed for reason or another (it happens often enough), it would have been another one of my secret failures, but no damage or embarrassment to anyone. :)
This is how it works - some developer has an itch and a bit of time, and he scratches it right away, and then gets on with his regular day-to-day programming.
- Hessu