¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io
Date

Re: Best Linux for Ham Radio

 

¿ªÔÆÌåÓý

Which bands are these people using? KD5UGY

On 7/10/24 08:48, Al - KD2PNR via groups.io wrote:

Well, after using various version of Linux (or similar Unix? based OS's), I think you would be best served with Mint, at least as a place to start with Linux. Personally I have only run it occasionally just as a learning experience, but it has always been easy and the most intuitive for former Windoze users. I have no idea about ham packages, but I assume they are plentiful, as it is an Ubuntu base. I have been using Fedora with the KDE desktop for many many years now, and I know it and like it, BUT it is probably the most bleeding edge variant - other than some of the development feeds - and it is always changing. This requires a good bit of knowledge about what is going on under the hood, and the ability to build much of what you want on your machine yourself. Because of this, and the fact it is not as heavily used by others, for a first user, I would not recommend Fedora.

Good luck and have fun. Oh, BTW, I find that I still am occasionally forced to use Windoze for some things, as no similar software is available un any form of Linux. (I'm lookin at you Bridgeccom and Rig Expert to name a couple)

Al? KD2PNR


Re: binary vs flatpak?

 

Thank you for the response Dave - you're right, KiCAD is one of the FlatPak programs I installed.? I notice the "Software Manager" in Mint 21.x gives a choice of flatpak version 8.0.3 at 7.1 GB or "System Package" of version 6.0.2+dfsg-1 at 80 GB.? Seems like FlatPak would be the choice here?? So far KiCAD has been working good for me with FlatPak.

You wrote: "Building (or sometimes installing) a binary, can result in some unsupported dependency issues you'll need to figure out and fix manually.? Sometimes that is easy, sometimes you end in nested dependency hell!?"

That has been my biggest problem with Linux - just not standardized enough for folks like me.? That's what makes the "idea" of the "Ideal" one file install package so appealing.? While I've been knocking around computers for a lot of years, I wrote my first software program (celestial navigation) in a very basic "Basic" back in 1986 this switch to Linux at almost 80 yrs old is sorta on the slow side for me.? I'm still learning, just at a slower pace than a few yrs back.

Forums like this are a really BIG help - mostly just lurking and reading without so much posting.

73 de Ken H> K9FV


Re: Best Linux for Ham Radio

 

Also, just in case there are people that don't know, I'm a Fedora packager and maintain most of the ham radio related applications including FLxxx suite and WSJT-X. I try to keep everything up to date but you can always reach out if you find that's not the case. I'm a volunteer and it's a hobby just like ham radio so I occasionally miss new app releases.

Thanks,
Richard
KF5OIM


Re: binary vs flatpak?

 

I find that when you are installing an app from the Software Manager you often find two versions of the app you want to install.

The Native binary package and the flatpak.

I have found in many (most) cases that the binary package version is behind (sometimes WAY behind) the flatpack version.

So flatpak it is.

My $0.02.

73
Danny, K5CG
HH 550-0609
SKCC 14257

----- Original Message -----
From: "Dave, G?WBX via groups.io" <g8kbvdave@...>
To: "linuxham" <[email protected]>
Sent: Wednesday, July 10, 2024 4:08:37 AM
Subject: Re: [linuxham] binary vs flatpak?

LMDE (Linux Mint Debian Edition) V5 (due for upgrade here VERY soon!)

DOES automatically find and install "Flatpak" applications (such as
KiCad and others) just fine, along with the usual Binary install's.

Just follow the Flatpak install instructions, so that they are correctly
registered with, known by the updating systems can keep tabs on them.


Re Flatpak vs Binary, I guess native Binary (as in compiled and built
locally) will probably launch and run a sniff faster than a Flatpak.?
But a Flatpak application comes with it's own baggage of dependencies,
so will (usually) always run.

Building (or sometimes installing) a binary, can result in some
unsupported dependency issues you'll need to figure out and fix
manually.? Sometimes that is easy, sometimes you end in nested
dependency hell!? (To say the least!)

Do what you need to do, it's your system, your choices.? But that's the
thing, you have choices!

73.

Dave G0WBX.

--
Created on and sent from a Unix like PC running and using free and open source software:


Re: Best Linux for Ham Radio

 

Like several in this thread, I have long since given up on Microsoft. I divorced myself from Windoz almost 17 years ago and I do not regret a minute of it. No more viruses....don't need an antivirus application. No more email worms. Updates are a pleasant few minutes vs the hour or more with all the Windoz rebooting. Forget all the stigma of years past about Linux being only for programmers and computer nerds. All that has changed considerably these days. It takes little hardware resources to run and even some of the? older computers work well with Linux.

I have tried several distros of Linux. Some have a good installer some do not. Some have a very good GUI, some do not. Some are fast and efficient some are not. In the end it becomes a matter of preferences. You have to make the choice. Popular opinion rarely suits the individual in this matter.

After years of downloading and trying various ones, I have settled on Linux Mint Debian Edition (now at version 6 - Debian 12). It is built to be very stable from the start, and the Cinnamon desktop is easy to use and extremely configurable. You can even make it look and feel like Windoz if you really miss it that much. Otherwise, start over and learn the new world of Linux. If you are transitioning from Windoz, you would be hard pressed to find a better place to land.

There is little need for the command line, but it is available in a terminal window if needed.?

The added plus of the Debian base is a seamless move to the Pi and Pi OS, a Debian base as well.

Programs like FLDIGI and WSJT-X have Linux versions you can run natively on Linux. Others are not so easy, but are do-able. WinLINK Express is one of those Windoz-only type. But many have been able to use it on Linux anyway with some help. Windows only stuff like Microsoft Office can be replaced with a Linux alternative called LibreOffice. It reads and writes all the MSOffice files, and works very much like the expensive stuff...but it is free or you can donate.?

There is help. Lots of info online and help from those of us hams who have already made the jump.

AD5XJ Ken


Re: Best Linux for Ham Radio

 

I have heard some good things about Arch, too. But I'm happy with Tumbleweed and it's been extremely stable. And I totally get the advantages that those of us have with rolling release distros. I do know personally though of two developers that will not work with the Arch team, so no AUR packages that are official from them. I only heard one side of that so I don't know which side of the issue the problem was really on.

As to, say, deb packages from web sites, it isn't just that simple as to look for a deb that matches your distro release funny name. You will have no way to know what exact lib versions that package was built against as it is not an official build. It would have been built on a 3rd party system, with whatever versions of libs were installed at the time. That's one of the things I like about Tumbleweed and it's official build service hosted 3rd party repos. When libs get changed, builds get triggered automatically and packages get updated and pushed after testing (that happens very fast). You never have a lib version mismatch or even a minor point mismatch, so that enhances stability. Plus all of the updates happen in the repos so when I do an update, it's right there in one place with no hunting by me needed going from web site to web site like you have to do in Windows. Codecs get handled the same way.

I also don't like or want some distro telling me I have one or a very few choices of desktop environments. I love KDE (Plasma 6 with Wayland) and I'll not have a distro team telling me that I can't have a fully supported and right up to date version of all of that. TW allows for any of the DEs to be selected and used, not just one, and it is not a messed with DE either.

Anyway, just my 2 cents on it.

Rick Kunath, K9AO


Re: Best Linux for Ham Radio

Robert S Jenkins, KG4KGL
 

On Jul 10, 2024, at 09:49, Al - KD2PNR via groups.io <ahw609@...> wrote:

?
Good luck and have fun. Oh, BTW, I find that I still am occasionally forced to use Windoze for some things, as no similar software is available un any form of Linux. (I'm lookin at you Bridgeccom and Rig Expert to name a couple)
For those apps, I would use a windows emulator.

I rid my home use of windows, decades ago. I still have to put up with it at work.

Robert
KG4KGL


Re: Best Linux for Ham Radio

 

P.S...

AND there are PLENTY of ham radio programs available as part of the "packages available" in Manjaro, Archinux, Red Hat, and MANY other distributions that are not related to Debian and Ubuntu...as in scores of them.


On Wednesday, July 10, 2024, Bob Finch, W9YA <w9ya@...> wrote:
> Robert is right...Manjaro and Archinux are examples where the ham radio stuff is kept as up to date as the software's author allows for.
>
> David sorry, I don't speak up here much, but today is an exception. It appears you haven't experienced a rolling distro like Manjaro (or Archinux). Compilation can (and is) completely automated as part of the update process. When automated it is done within a "sandbox" which makes the issues related to live system compilation evaporate. You can also compile manually and adaptably as needed still using "da sandbox".
>
> In other words.... IT REALLY ISN'T A PROBLEM TO USE A DISTRO THAT ISN'T DEBIAN BASED.
>
> I promise.
>
> Er um;
>
> Nothing wrong with using any particular version (distribution) of Linux. We should all try to remember that.
>
> I'll crawl back in my hole now.
>
> es vy 73 de "Baab" w9ya
>
>
> On Tuesday, July 9, 2024, Robert S Jenkins, KG4KGL <Qrp@...> wrote:
>>
>>
>> On Jul 9, 2024, at 20:00, David Ranch, KI6ZHD via <linuxham-fld=[email protected]> wrote:
>>
>> ?
>> I would argue that the path of least resistance to be able to run the newest and greatest would be anything Ubuntu based be it the real Ubuntu, or re-spins like Linux Mint, etc.?? I state this because there are programs that are either not current or outright NOT available via the distro's native "program download" tool but pre-built .deb packages are available to download from the program's website.? For example:
>>
>> ?? wsjt-x :
>>
>>
>> A distant second might be Raspberry Pi OS and then maybe Fedora.? After that, all other Linux distros are fine but you'll be on your own to compile things yourself if you want the news and greatest.
>>
>> --David
>> KI6ZHD
>>
>> This might be true of some rare distro(s), but not true for most major distros.?
>> Robert?
>> KG4KGL
>> _._,_._,_
>> ________________________________
>> Groups.io Links:
>>
>> You receive all messages sent to this group.
>>
>> View/Reply Online (#53043) | Reply To Group | Mute This Topic | New Topic
>> Your Subscription | Contact Group Owner | Unsubscribe [w9ya@...]
>>
>> _._,_._,_
> _._,_._,_
> ________________________________
> Groups.io Links:
>
> You receive all messages sent to this group.
>
> View/Reply Online (#53053) | Reply To Group | Mute This Topic | New Topic
> Your Subscription | Contact Group Owner | Unsubscribe [w9ya@...]
>
> _._,_._,_


Re: Best Linux for Ham Radio

 

Well, after using various version of Linux (or similar Unix? based OS's), I think you would be best served with Mint, at least as a place to start with Linux. Personally I have only run it occasionally just as a learning experience, but it has always been easy and the most intuitive for former Windoze users. I have no idea about ham packages, but I assume they are plentiful, as it is an Ubuntu base. I have been using Fedora with the KDE desktop for many many years now, and I know it and like it, BUT it is probably the most bleeding edge variant - other than some of the development feeds - and it is always changing. This requires a good bit of knowledge about what is going on under the hood, and the ability to build much of what you want on your machine yourself. Because of this, and the fact it is not as heavily used by others, for a first user, I would not recommend Fedora.

Good luck and have fun. Oh, BTW, I find that I still am occasionally forced to use Windoze for some things, as no similar software is available un any form of Linux. (I'm lookin at you Bridgeccom and Rig Expert to name a couple)

Al? KD2PNR


Re: Best Linux for Ham Radio

 

Robert is right...Manjaro and Archinux are examples where the ham radio stuff is kept as up to date as the software's author allows for.

David sorry, I don't speak up here much, but today is an exception. It appears you haven't experienced a rolling distro like Manjaro (or Archinux). Compilation can (and is) completely automated as part of the update process. When automated it is done within a "sandbox" which makes the issues related to live system compilation evaporate. You can also compile manually and adaptably as needed still using "da sandbox".

In other words.... IT REALLY ISN'T A PROBLEM TO USE A DISTRO THAT ISN'T DEBIAN BASED.

I promise.

Er um;

Nothing wrong with using any particular version (distribution) of Linux. We should all try to remember that.

I'll crawl back in my hole now.

es vy 73 de "Baab" w9ya


On Tuesday, July 9, 2024, Robert S Jenkins, KG4KGL <Qrp@...> wrote:
>
>
> On Jul 9, 2024, at 20:00, David Ranch, KI6ZHD via <linuxham-fld=[email protected]> wrote:
>
> ?
> I would argue that the path of least resistance to be able to run the newest and greatest would be anything Ubuntu based be it the real Ubuntu, or re-spins like Linux Mint, etc.?? I state this because there are programs that are either not current or outright NOT available via the distro's native "program download" tool but pre-built .deb packages are available to download from the program's website.? For example:
>
> ?? wsjt-x :
>
>
> A distant second might be Raspberry Pi OS and then maybe Fedora.? After that, all other Linux distros are fine but you'll be on your own to compile things yourself if you want the news and greatest.
>
> --David
> KI6ZHD
>
> This might be true of some rare distro(s), but not true for most major distros.?
> Robert?
> KG4KGL
> _._,_._,_
> ________________________________
> Groups.io Links:
>
> You receive all messages sent to this group.
>
> View/Reply Online (#53043) | Reply To Group | Mute This Topic | New Topic
> Your Subscription | Contact Group Owner | Unsubscribe [w9ya@...]
>
> _._,_._,_


Re: flrig 2.0.05.66 development test version posted

 

¿ªÔÆÌåÓý

I will look at those and test with my 7300.? Probably not until leter this evening.? I am having a full round of cardiac testing today; 10 AM to 4 PM.? She isn't expecting anything unusual, by my cardiologist wants to make sure I am a healthy 85 year old groom ?.

Dave

On 7/9/24 21:57, Cliff, AE5ZA wrote:

Dave,

Using the 7300:

Well, now I can't duplicate the pause I was seeing before with .66. The new .67 seems to work normally with the dropdown panel opening or closing.

The NB "on" label is still slow in displaying the "on", a couple seconds wait most times on both the Mac and Pi where the the other buttons with text added on click seem fine, pretty much instant. Go figure. Not an issue to worry about, but just odd. The button light is instant on all, even the NB.

Another VERY minor issue, but if you want the GUI to be consistent, The Attenuator button will turn off an active PreAmp button if clicked, but the PreAmp button will not turn on if the ATT is active. It must be manually turned off first.

73,
Cliff, AE5ZA



On Jul 9, 2024, at 11:25, Dave, W1HKJ via <w1hkj@...> wrote:

Dave,

You should be testing 2.0.05.67
posted at

Index of /ae5za

Dave

On 7/6/24 15:46, Dave, G?WBX via wrote:
Hi Dave.

Sorry, but 2.0.05.66 STILL has the "sticky extra controls" button issue.? While the UI hangs for some time, awaiting a non existent response from the radio, for a simple command sent to turn something on or off.

Even though it uses :-
waitResponse(progStatus.serial_timeout);?? ( In dialogs.cxx at line 2006 )

instead of...

waitResponse(200);

The UI still hangs for some 7 seconds.

Commenting out that entire line, and all is good again, so why is it needed?

I think the problem is that calling "waitResponse()" in general is the issue, when there is *NO* response from the radio for some command sent to it.? (Turning the TS870's Beat Cancel function on/off for example.)

Even "waitResponse(0)" or other single digit figure, still causes the 7 second hang.

I'm running the control serial link at 57600bd too, with RTS/CTS handshake, as required by many Kenwood radios.

It is only those user created functions in the slide out (or docked) "fldigi extra controls" facility that seems to be affected, with the TS870, but the Icom PCR1000 and Yaesu FT736 rigs are affected in a much greater way, as many of the "normal" functions do not return anything from the rig.? Especially the 736.

That block of code (in dialogs.cxx) where waitResponse() is, as far as I can see, has not changed, and that is the only instance in dialogs.cxx

But I guess the "guts" of waitResponse() has, or some other code being invoked by waitResponse() is being invoked, but what and where?

(I have never found out how to discover which included file contains a function being invoked in any given source file.? It's probably easy, just I don't know how.)


If you wish, we could do a Zoom call, and share screen's etc.? If that would help?? (Time differences permitting.)

All the best Dave (HKJ)

Dave G0WBX.







Re: binary vs flatpak?

 

LMDE (Linux Mint Debian Edition) V5 (due for upgrade here VERY soon!)

DOES automatically find and install "Flatpak" applications (such as KiCad and others) just fine, along with the usual Binary install's.

Just follow the Flatpak install instructions, so that they are correctly registered with, known by the updating systems can keep tabs on them.


Re Flatpak vs Binary, I guess native Binary (as in compiled and built locally) will probably launch and run a sniff faster than a Flatpak.? But a Flatpak application comes with it's own baggage of dependencies, so will (usually) always run.

Building (or sometimes installing) a binary, can result in some unsupported dependency issues you'll need to figure out and fix manually.? Sometimes that is easy, sometimes you end in nested dependency hell!? (To say the least!)

Do what you need to do, it's your system, your choices.? But that's the thing, you have choices!

73.

Dave G0WBX.

--
Created on and sent from a Unix like PC running and using free and open source software:


Re: binary vs flatpak?

 

¿ªÔÆÌåÓý


I agree with Jason's list here though I think he missed one of the newer ones... (Docker) containers!? Each of these systems have their pros/cons but I can whole heartedly agree that Snaps are annoying and they sure clutter things up.? For example, check out all this mess when you look at the "mount" listing on.? That's 51 snaps for a pretty vanilla Ubuntu 22.04 host!
--
$ mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=7991608k,nr_inodes=1997902,mode=755,inode64)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=1606056k,mode=755,inode64)
/dev/sda5 on / type ext4 (rw,relatime,errors=remount-ro)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,inode64)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k,inode64)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=29,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=18860)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
ramfs on /run/credentials/systemd-sysusers.service type ramfs (ro,nosuid,nodev,noexec,relatime,mode=700)
/var/lib/snapd/snaps/bare_5.snap on /snap/bare/5 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide)
/var/lib/snapd/snaps/canonical-livepatch_278.snap on /snap/canonical-livepatch/278 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide)
/var/lib/snapd/snaps/canonical-livepatch_282.snap on /snap/canonical-livepatch/282 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide)
/var/lib/snapd/snaps/chromium_2897.snap on /snap/chromium/2897 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide)
/var/lib/snapd/snaps/chromium_2905.snap on /snap/chromium/2905 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide)
/var/lib/snapd/snaps/core_16928.snap on /snap/core/16928 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide)
/var/lib/snapd/snaps/core18_2823.snap on /snap/core18/2823 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide)
/var/lib/snapd/snaps/core_17200.snap on /snap/core/17200 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide)
/var/lib/snapd/snaps/core18_2829.snap on /snap/core18/2829 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide)
/var/lib/snapd/snaps/core20_2264.snap on /snap/core20/2264 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide)
/var/lib/snapd/snaps/core20_2318.snap on /snap/core20/2318 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide)
/var/lib/snapd/snaps/core22_1122.snap on /snap/core22/1122 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide)
/var/lib/snapd/snaps/core22_1380.snap on /snap/core22/1380 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide)
/var/lib/snapd/snaps/cups_1052.snap on /snap/cups/1052 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide)
/var/lib/snapd/snaps/core24_423.snap on /snap/core24/423 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide)
/var/lib/snapd/snaps/cups_1058.snap on /snap/cups/1058 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide)
/var/lib/snapd/snaps/firefox_4451.snap on /snap/firefox/4451 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide)
/var/lib/snapd/snaps/firefox_4483.snap on /snap/firefox/4483 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide)
/var/lib/snapd/snaps/gnome-3-28-1804_198.snap on /snap/gnome-3-28-1804/198 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide)
/var/lib/snapd/snaps/gnome-3-28-1804_194.snap on /snap/gnome-3-28-1804/194 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide)
/var/lib/snapd/snaps/gnome-3-38-2004_140.snap on /snap/gnome-3-38-2004/140 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide)
/var/lib/snapd/snaps/gnome-3-38-2004_143.snap on /snap/gnome-3-38-2004/143 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide)
/var/lib/snapd/snaps/gnome-42-2204_141.snap on /snap/gnome-42-2204/141 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide)
/var/lib/snapd/snaps/gnome-42-2204_176.snap on /snap/gnome-42-2204/176 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide)
/var/lib/snapd/snaps/gnome-46-2404_26.snap on /snap/gnome-46-2404/26 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide)
/var/lib/snapd/snaps/gtk-common-themes_1534.snap on /snap/gtk-common-themes/1534 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide)
/var/lib/snapd/snaps/gtk-common-themes_1535.snap on /snap/gtk-common-themes/1535 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide)
/var/lib/snapd/snaps/kde-frameworks-5-96-qt-5-15-5-core20_7.snap on /snap/kde-frameworks-5-96-qt-5-15-5-core20/7 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide)
/var/lib/snapd/snaps/kde-frameworks-5-core18_32.snap on /snap/kde-frameworks-5-core18/32 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide)
/var/lib/snapd/snaps/kde-frameworks-5-core18_35.snap on /snap/kde-frameworks-5-core18/35 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide)
/var/lib/snapd/snaps/kf5-5-104-qt-5-15-8-core22_9.snap on /snap/kf5-5-104-qt-5-15-8-core22/9 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide)
/var/lib/snapd/snaps/kf5-5-108-qt-5-15-10-core22_5.snap on /snap/kf5-5-108-qt-5-15-10-core22/5 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide)
/var/lib/snapd/snaps/kf5-5-111-qt-5-15-11-core22_5.snap on /snap/kf5-5-111-qt-5-15-11-core22/5 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide)
/var/lib/snapd/snaps/kf5-5-111-qt-5-15-11-core22_7.snap on /snap/kf5-5-111-qt-5-15-11-core22/7 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide)
/var/lib/snapd/snaps/kf5-5-113-qt-5-15-11-core22_1.snap on /snap/kf5-5-113-qt-5-15-11-core22/1 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide)
/var/lib/snapd/snaps/krita_100.snap on /snap/krita/100 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide)
/var/lib/snapd/snaps/krita_104.snap on /snap/krita/104 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide)
/var/lib/snapd/snaps/mesa-2404_44.snap on /snap/mesa-2404/44 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide)
/var/lib/snapd/snaps/snap-store_1113.snap on /snap/snap-store/1113 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide)
/var/lib/snapd/snaps/snap-store_959.snap on /snap/snap-store/959 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide)
/var/lib/snapd/snaps/snapd_21184.snap on /snap/snapd/21184 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide)
/var/lib/snapd/snaps/snapd_21759.snap on /snap/snapd/21759 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide)
/dev/sda5 on /var/snap/firefox/common/host-hunspell type ext4 (ro,noexec,noatime,errors=remount-ro)
/var/lib/snapd/snaps/snapd-desktop-integration_157.snap on /snap/snapd-desktop-integration/157 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide)
/var/lib/snapd/snaps/snapd-desktop-integration_83.snap on /snap/snapd-desktop-integration/83 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide)
/dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run/snapd/ns type tmpfs (rw,nosuid,nodev,noexec,relatime,size=1606056k,mode=755,inode64)
nsfs on /run/snapd/ns/canonical-livepatch.mnt type nsfs (rw)
nsfs on /run/snapd/ns/cups.mnt type nsfs (rw)
nsfs on /run/snapd/ns/snapd-desktop-integration.mnt type nsfs (rw)
tracefs on /sys/kernel/debug/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=1606052k,nr_inodes=401513,mode=700,uid=1000,gid=1000,inode64)
portal on /run/user/1000/doc type fuse.portal (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
nsfs on /run/snapd/ns/snap-store.mnt type nsfs (rw)
nsfs on /run/snapd/ns/firefox.mnt type nsfs (rw)
--

On 07/09/2024 02:05 PM, Jason Turning wrote:

This write up on Flatpaks though old is still my favorite:

There are actually three formats trying to accomplish the same thing by including specific libraries and making it easier for developers () to distribute software, championed by Red Hat (that should say everything), championed by Canonical (both I believe desire running an ap store like Google and Apple so they can take a chunk of sales as GNU/Linux eventually replaces Microsoft Spyware), and which is the more free option. I personally don't use Flatpak or Snap and will remove them from any distro I'm using or trying. I do have a couple crypto related appimages that I use, but I prefer the repo software or compiling it myself. But if you need them in a pinch, you can use what works.

73
Jason - WY7JT


Re: binary vs flatpak?

Robert S Jenkins, KG4KGL
 

On Jul 9, 2024, at 21:12, k9ao via groups.io <k9ao@...> wrote:

?If that is actually necessary then they are running the wrong distro(s).

If it isn't necessary then they need a better mentor :) so they can stick to one distro and really understand it well. (Or switch to the right distro and stick with that.)

Rick Kunath, K9AO
These are people that are beyond needing a mentor. :D

Robert
KG4KGL


Re: Best Linux for Ham Radio

Robert S Jenkins, KG4KGL
 

On Jul 9, 2024, at 21:10, k9ao via groups.io <k9ao@...> wrote:



No wrong answer other than to not go Linux all the way :)
That is why I have Apple OS, with its BSD underpinning. As long as it is not Windows!

Robert
KG4KGL


Re: flrig 2.0.05.66 development test version posted

Cliff, AE5ZA
 

¿ªÔÆÌåÓý

Dave,

Using the 7300:

Well, now I can't duplicate the pause I was seeing before with .66. The new .67 seems to work normally with the dropdown panel opening or closing.

The NB "on" label is still slow in displaying the "on", a couple seconds wait most times on both the Mac and Pi where the the other buttons with text added on click seem fine, pretty much instant. Go figure. Not an issue to worry about, but just odd. The button light is instant on all, even the NB.

Another VERY minor issue, but if you want the GUI to be consistent, The Attenuator button will turn off an active PreAmp button if clicked, but the PreAmp button will not turn on if the ATT is active. It must be manually turned off first.

73,
Cliff, AE5ZA



On Jul 9, 2024, at 11:25, Dave, W1HKJ via <w1hkj@...> wrote:

Dave,

You should be testing 2.0.05.67
posted at

Index of /ae5za

Dave

On 7/6/24 15:46, Dave, G?WBX via wrote:
Hi Dave.

Sorry, but 2.0.05.66 STILL has the "sticky extra controls" button issue.? While the UI hangs for some time, awaiting a non existent response from the radio, for a simple command sent to turn something on or off.

Even though it uses :-
waitResponse(progStatus.serial_timeout);?? ( In dialogs.cxx at line 2006 )

instead of...

waitResponse(200);

The UI still hangs for some 7 seconds.

Commenting out that entire line, and all is good again, so why is it needed?

I think the problem is that calling "waitResponse()" in general is the issue, when there is *NO* response from the radio for some command sent to it.? (Turning the TS870's Beat Cancel function on/off for example.)

Even "waitResponse(0)" or other single digit figure, still causes the 7 second hang.

I'm running the control serial link at 57600bd too, with RTS/CTS handshake, as required by many Kenwood radios.

It is only those user created functions in the slide out (or docked) "fldigi extra controls" facility that seems to be affected, with the TS870, but the Icom PCR1000 and Yaesu FT736 rigs are affected in a much greater way, as many of the "normal" functions do not return anything from the rig.? Especially the 736.

That block of code (in dialogs.cxx) where waitResponse() is, as far as I can see, has not changed, and that is the only instance in dialogs.cxx

But I guess the "guts" of waitResponse() has, or some other code being invoked by waitResponse() is being invoked, but what and where?

(I have never found out how to discover which included file contains a function being invoked in any given source file.? It's probably easy, just I don't know how.)


If you wish, we could do a Zoom call, and share screen's etc.? If that would help?? (Time differences permitting.)

All the best Dave (HKJ)

Dave G0WBX.






Re: Best Linux for Ham Radio

 

On Tue, Jul 9, 2024 at 7:00?PM David Ranch, KI6ZHD via <linuxham-fld=[email protected]> wrote:

I would argue that the path of least resistance to be able to run the newest and greatest would be anything Ubuntu based be it the real Ubuntu, or re-spins like Linux Mint, etc.?? I state this because there are programs that are either not current or outright NOT available via the distro's native "program download" tool but pre-built .deb packages are available to download from the program's website.? For example:

?? wsjt-x :


A distant second might be Raspberry Pi OS and then maybe Fedora.? After that, all other Linux distros are fine but you'll be on your own to compile things yourself if you want the news and greatest.

To echo David's statements here, it really all comes down to who is actually maintaining?the software.

For Fedora, I maintain most of the ham radio related packages and I do my best to keep them up to date, but to be clear, my $DAYJOB has nothing to do with ham radio and is only tangentially related to linux. I'm a volunteer who has literally spent thousands of unpaid hours maintaining packages for Fedora. It's a labor of love, but as soon as you assert expectations of my time, we have an issue.

This is both the blessing and the curse of open source software and distributions.?

Thanks,
Richard
KF5OIM


Re: binary vs flatpak?

 

If that is actually necessary then they are running the wrong distro(s).

If it isn't necessary then they need a better mentor :) so they can stick to one distro and really understand it well. (Or switch to the right distro and stick with that.)

Rick Kunath, K9AO


Re: Best Linux for Ham Radio

 

The same is true for Opensuse Tumbleweed, but unlike the need for using 3rd party web sites, officially sponsored package managers make all of these same applications available via the officially sponsored and hosted 3rd party repos and the via ackage manager. Especially and including WSJTX and it's variants and all of the stable as well as very bleeding edge stuff. Any app I ever needed.

Now, I do build things from source. But this is done when I am either developing software or assisting with testing on very alpha released stuff, or working through bugfixes on released packages. In that case it is being done via git, as usual.

No need to hunt up updates from web sites and all of the updating is handled in one fell swoop as it should be, unlike the Windows world.

Like I said, I can't say enough good stuff about Tumbleweed. Ubuntu, much as lots of folks love it and swear by it, is too messed with for me. I like standard based Linux/UNIX. But a distro decision is something each of us needs to make on their own. My 5 decades of UNIX experience might have me shaking my head about some thing or other that some distro did, where someone newer would never know better.

No wrong answer other than to not go Linux all the way :)

73,
Rick Kunath, K9AO


Re: Best Linux for Ham Radio

Robert S Jenkins, KG4KGL
 

¿ªÔÆÌåÓý



On Jul 9, 2024, at 20:00, David Ranch, KI6ZHD via groups.io <linuxham-fld@...> wrote:

?
I would argue that the path of least resistance to be able to run the newest and greatest would be anything Ubuntu based be it the real Ubuntu, or re-spins like Linux Mint, etc.?? I state this because there are programs that are either not current or outright NOT available via the distro's native "program download" tool but pre-built .deb packages are available to download from the program's website.? For example:

?? wsjt-x :


A distant second might be Raspberry Pi OS and then maybe Fedora.? After that, all other Linux distros are fine but you'll be on your own to compile things yourself if you want the news and greatest.

--David
KI6ZHD

This might be true of some rare distro(s), but not true for most major distros.?

Robert?
KG4KGL