Hypothetically, When you buy an iPhone, do you expect to also get the latest model when it is released?
That being said, Apple also releases iOS updates to previous phones, even after they've been paid for.
If this doesn't seem strange to you, then perhaps the same thought process of buying a specific version of software with the expectation that it will work for several years is not unreasonable.
I see no need for a subscription model on every type of software. I pay you once, you ensure that it's written in a way that will continue to work for years to come. End of transaction, as far as I'm concerned.
1. It makes sense that Google wants to stop apps from abusing their storage platform. There are a lot of projects that abuse the data storage capacity. There was that one app that converted files to Base64 or something and was storing files that way as email text. Obviously not cool. However, Google needs to be explicitly clear on expectations and throw some people-power behind the reviews, since many are being denied by (seemingly) some automated process.
2. The second issue I see is that it will encourage less secure methods of using these apps.
SMSBackup+ in particular is discussing the possibility of moving to "App Passwords" to bypass 2FA and provide the app access it needs to upload and store the data.
Issue being, App Passwords are incredibly fragile, they provide near-unfettered access to IMAP and other account features with no auditing.
Caveat emptor and all that.
I think SMSBackup+, specifically, has a bit of a gray line as SMS messages can technically be sent via email and vice versa, (among other similarities). It's a shame that Google is becoming so draconian about their data storage uses.
I agree with your sentiment, but part of the key difference for me is that SMSBackup+ is open source. I've been building the app myself and using it for years, so I'm very certain what it's doing and not doing.
This may or may not apply to the other apps being affected by this ban.
The facts stand, as have been reiterated in the thread above:
- Firefighting airplanes can effectively spray in a way that doesn't harm trees (by releasing the 12,000+ gallons over a very large area)
- Buildings are fine in extended substantial downpours (which is significantly less water per second than an air-tanker dump)
To your thought's end:
- Spraying a building with a plane in such a configuration would not collapse it
Yes, it's possible to spray the cathedral with water in such a way that it will not collapse it, but that configuration is that very little water gets on the cathedral, and is instead spread over pretty much the entire island in the Seine.
At this point in time, however, it likely doesn't matter. Since most of the building has collapsed already, due to the fire. Like we said it would.
Given the leaps and bounds of development in this area recently, I wouldn't call HackRF a go-to device anymore (compared to the more recent devices) but yes- any of them totally would be able to pick this up.
>I sent him a link to Mouser, a catalog where you can buy a 0.006 x 0.003 inch coupler. Turns out that’s the exact coupler in all the images in the story.
I did a super quick search, and sure enough, yep- the images in the article are most likely a $0.38/each 0603 coupler.
Many packages use rolling versions from git commits, so while the PKGBUILDs don't get updated, any time a user re-runs makepkg on that PKGBUILD the latest commit is pulled and built.
In those cases, a PKGBUILD might be months or years old, but still consistently up to date and valid.