Airspy USB on Raspberry Pi model 2B, doesn't work in Buster?

Obvious question: is there anything relevant in the logs?

Related point: Buster seems to make rather more use of logging than Stretch and predecessors, so you might want to see if the logrotate and logwatch packages are installed: I did an in-situ upgrade from Stretch to Buster which did not install them, so I added them manually. Then again I'm used to having these packages installed on my bigger Fedora boxes and I have also modified /etc/aliases so root's mail for every host on my LAN gets redirected to my normal login on the laptop that I usually work from.

Martin,

Thanks for that suggestion. dmesg showed just the existence of the USB device, and that looked correct. That's really the only log inspection command I've used. Should I be looking elsewhere?

I've found it useful to have tail running on the messages log in a terminal window if I'm having trouble accessing a USB device. This has helped a lot when trouble-shooting USB serial adapters and also when discovering and reporting a USB mass-storage bug which prevented my laptop from seeing both the built-in memory and an SD-card in a Medion S.3747 PNA when it was connected to the laptop via USB.

Just run "sudo tail -f /var/log/messages" in the terminal window. Kill tail with Ctrl-C when you've finished using it.

On 09/08/2019 12:08, Martin Gregorie wrote: [] > I've found it useful to have tail running on the messages log in a > terminal window if I'm having trouble accessing a USB device. This has > helped a lot when trouble-shooting USB serial adapters and also when > discovering and reporting a USB mass-storage bug which prevented my > laptop from seeing both the built-in memory and an SD-card in a Medion > S.3747 PNA when it was connected to the laptop via USB. > > Just run "sudo tail -f /var/log/messages" in the terminal window. Kill > tail with Ctrl-C when you've finished using it.

Thanks for that suggestion! I ran that, and tried starting the program, but no new messages appeared. In fact, the time of the last message was midnight "today". But that tip will be also useful for the future.

Its worthwhile grepping /var/log/* - providing that you know a program name and/or log-format timestamp to search on - if there's nothing in messages.

There's a lot to be said for tail -F - which tracks when the log file cycles.

-- Steve O'Hara-Smith | Directable Mirror Arrays C:\>WIN | A better way to focus the sun The computer obeys and wins. | licences available see You lose and Bill collects. |

Since it is not mentioned in this thread yet: have you checked for correct permissions? The user running the program needs to have correct permissions to access the device. This is a very common problem with usb devices other than the most common devices like keyboards, mice and so on.

A quick test to check if this is the problem is to try to run the program as the root user (example: sudo program ...) if it works, then you most likely have a permissions problem.

And then you get to fix that via udevadm and friends...

Ah well, the joys of shared computing. That was why personal comuting was such a great hit while it lasted. One user, my machine. No need to negotiate rights with anyone.

...for Virus writers...

while it lasted. One user, my machine. No need to

There are lots of kinds of protection against malware. The only reliable one could I ever find was Brain 1.0. So far it has kept me safe and never failed me once. All the others cause lots of hassle and extra effort, but none of them is reliable. On the contrary, by making everything more complicated and harder to grasp and keep on top of, they make it easier for unintended immigrants to slip through.

Adding a well-thought-out file ownership and access permission system helps a lot, provided users don't do terminally stupid things like assigning superuser properties to their normal login. This is where Unix introduced a sensible access control system, which Linux also uses, while Windows in inherently insecure by design.

The only major item missing from *nix implementations is more rigorous hardware implemented controls on memory access by running processes. Intel has a minimal, but seemingly adequate set of hardware protection rings but no current operating systems appear to make full use of it: among other things, proper use of the hardware rings of protection would prevent scripted nasties, etc in e-mails and web pages from accessing any memory outside their immediate environment.

I've used mainframe operating systems that could do exactly what I've described, so know it can be done and, what's more, do that without interfering with legitimate users doing what they need to do.

Windose was designed as a single user non networked design. What Gates SHOULD have done is intsead of NT, adapted and written a pretty face for unix/linux

Quite - because until NT arrived Windows nothing more than a graphical desktop sat on top of MSDOS 7, and MSDOS had never heard of security, and even networking was just a 3rd party add-on until Windows 3.11 appeared.

Exactly so. The real surprise is that OS/2, the joint project with IBM, wasn't better than it was: by then IBM was starting to write decent operating systems, starting with Future Series, (which morphed into OS/

Thanks, Torfinn!

That fixed it. I'm annoyed I didn't think to try that before! For the moment, I'll pass that into the developer, and I've added a sudo in the script I use to run the software.

Yes, the name is known. I just tried that after a successful start, but if there were any earlier error messages (due to lack of permission) they weren't present. Oh, well. But next time.....

Fixed:

On Sat, 10 Aug 2019 12:26:56 -0000 (UTC), Martin Gregorie declaimed the following:

Some of them did get in... Since some of WinNT was inspired by DEC's VMS... And I doubt anyone would claim VMS is an insecure OS given how heavily it was used for defense related work.

Unfortunately, they didn't scrap the MS-DOS command line and file naming... (Come on... Why allow drives/partitions to have volume NAMES when you can't use the name to reference them! Strangely, AmigaOS better matched VMS when it came to things like volume and logical [which are NOT related to UNIX/Windows environment variables] names) and the requirement to maintain 16-bit compatibility probably made the user-level much weaker for security.

DEC's

An interesting read: thanks. I've done little to no development using NT, though I did a project or two using VAX VMS and DEC's database RDB.

The main things I remember about VMS were not much liking the concept of having a few massive utility programs and that noticing that there were a lot of similarities between the way the VMS command interpreter works and ICL's George 3 command interpreter - I liked this because I'd been a G3 sysadmin and found the similarities helpful when getting to grips with using VMS for development and writing scripts for it.

I knew a lot more about DEC's UNIX on Alphaserver boxes than I ever knew about VMS, but this was because by the time I met the Alphaserver I'd used several Unices and Unix workalikes (TSC Uniflex, Microware's OS-9 and Stratus VOS) and gotten to grips with Tandem's Guardian OS - not one of my favourites, but at least it was better than IBM's horrid MVS/370.

He'd already passed XENIX on to SCO by then.