Any new SD card image (based on Bookworm or Trixie) will necessitate moving the networking from dhcpcd to NetworkManager. Maybe that work took/is taking longer than planned and they have decided to wait until Trixie is officially released. Guesstimate by @abcd567 sounds very plausible to me.
Another point I don’t see discussed is FA’s sale of itself to Rockwell Collins in 2021. Now it is a very small part of the US defence behemoth RTX (current market cap ~ 155 billion USD), When these transactions go down, the resources allocated and priorities of the organization change based on what the new ownership wants. I have no knowledge that is the case for FA, but it is a pretty common occurrence. The way things worked before may not be how they do going forward.
Drawing from experience, i remember what it was like to have the big fish swallow you and you become the sucker fish on the side of the whale overnight. Suddenly you aren’t “family” anymore and you get food scraps and the worst room in the house.
Flightaware did announce the sale, but definitely kept it quiet nevertheless.
ADSBExchange sold itself and we have seen how the support of the independent feeders responded.
May have to rethink supporting Collins/Flightaware. Just shut down one of my two feeders.
Many things need to be updated and fixed: hardware, software and the “Other” reporting fiasco come to mind. If Flightaware does nothing to improve these, then why should any of us support them. Just asking the question. There are other deserving companies.
The ball is now in Collins Aerospace and Flightaware courts.
Ok, I sort of lost track of all that history. Rockwell International bought Collins Radio in the early 1970’s. I worked at Collins Radio – then Rockwell Collins for about half of my career.
Yes, “Collins Aerospace” is more accurately the entity that purchased FA. Trying to unpick what the current RTX consists of through mergers, acquisitions, rebranding, etc. is a real head spinner. Lawyers who deal in this type of work must have made a mint.
My intent on bringing it up was not that there was no public knowledge of the sale, but its possible relevance to software and hardware developments (or lack thereof) coming from FA. New management may have shelved some projects and set new objectives for the company.
Just adding my two sense in here. Most industrial embedded software (PiAware could be considered similar to the software that runs on Industrial computers or controllers as it really only is designed for one purpose.) doesn’t get updated very often if ever. If it’s running smoothly without too many bugs or issues and does its base function, why would you want to ruin that by adding extra features that most will never use? You could in theory have a dev and a stable branch, but that takes dev time away from potentially other important things, and I’d bet flightawares dev team is probably a hand full of people, not 100s like you might see at software companies.
If my unit is anything to go by, its definitely working just fine. 930 Day streak and bar the odd blip, I’ve rarely rebooted it.
For the PiAware image that could be considered a good analogy, since it’s designed to work out of the box on designated hardware and it limits its exposure. FA have taken over the repos and standard OS updates work okay from those.
But the problem is really the lack of engagement or communication from FA about this project and whether or not it will continue to be developed, since in this community it acts as a base layer for a raft of other tools, feeders and services.
The actual release version could stay the same for years, that’s not the problem for the reasons you describe – what matters is whether it’s doing that as part of an active production decision to run it that way as current software, or whether it’s doing that because it’s largely now abandonware.
I’d welcome a detailed post from FA staff allaying these concerns and detailing the next steps for PiAware and the associated hardware, about which they were once so enthusiastic.
These utils look very interesting. I have a friend who had a power outage and lost his SD card from it. After redoing the image from scratch with all the add-ons, I did a dd backup and then zipped it. This 1.5GB zip can be written to a new card but it has to be 32GB or larger, since all that empty space was also captured in the img.
I was looking for a way to do a smarter backup, maybe using restic. These RonR tools look really interesting since it looks like they give a quick way to get a working image back to a new card. I will check them out in due course. Thanks for the link.
My friend ended up getting the UPS hat for the RPi and I’ve got it automated. I’ll be writing that up in here shortly as a guide.
If you’re running the Desktop version of Raspberry Pi OS, there is an SD Card Copier program included which will copy your running SD card (or other media) to a new card in a USB adaptor, or any other USB device.
The copy will be a fully bootable copy of your running system. It also gets resized to fit the new card/USB stick/whatever.
Later Addition
For headless (Lite) version of RaspberryPi OS, try following two tools:
Nice one, thanks, I hadn’t noticed that. That’ll be handy for the Pi-hole install. I see it’s called piclone. For the feeders we’re using the PiAware image, so would need something terminal based we can add to that, and which can ideally make a .img. These RonR utils look very promising.
So The output from the aircraft isn’t changing or adding features.
So What’s decoding it doesn’t need to change.
(As is the world of global aviation hardware.)
Anything else is cosmetic GUI over the top of standardized data?
Bar some user edited changes and mods people here have added and would be neat if included. I’m not seeing much to develop when it’s not your average SaaS model.
Now if you want an example where continual development does go wrong…let me introduce you to 24H2
Or for asking for updates on user side development or been abandoned, a certain swedish upload package comes to mind.