Complain to other hardware vendors that they sell insecure crap or do not release updates :/
And yeah, it'll be Motorola from the next year on, but a proper, first party cooperation. I think that Motorola wants to become the answer to the question: "what's the best, safest android smartphone?"
(FWIW, sometimes when you _block_ the app from the Play Integrity API (in this pop-up) the app that wants to perform the check works, while it fails when you do not block it)
You're not syncing photos to anthropic services, you're not even using Claude code to run rclone for you, and specifically you're not ingesting every synchronised photo or video into the context.
You're not authorising CC to access your photos.
Claude Code is used to prepare the rclone run.
What do you mean that by using cc you're handing over your data (presumably synced photos) you're handing over your data"?
The comment I was responding to only said "just use claude code." So every single word you wrote in your reply is a hallucination.
If you genuinely believe that "just use claude code" means any of the things you wrote, you are definitely not careful enough to take the precautions necessary to contain commercial spyware. Claude Code would read your credentials and probe your files to "see if everything is set up correctly" and you won't think twice about it.
> OK, explain, what to the "just use Claude code" means in your opinion.
I see you didn't get the message. It's not about opinions. Don't add a bunch of extra meanings to suit your argument.
The original comment was:
> just use claude code to use rclone on a server and let it run automatically, its great and easy
First, it says "use claude code to use rclone." It's very simple English, yet it directly contradicts your claim that "you're not even using Claude code to run rclone for you."
> Because that's the only way I'd understand someone to go on such rant.
Yeah, no wonder given the above.
Going back to the original comment, it says it's easy. Easier than not using Claude Code, which is typing `rclone copy <source> .`. Every justification that you pulled out of thin air is more complicated than that.
> Is this what you'd do?
Again, you're not reading. Read my original comment. And the reply to your comment. I wouldn't use Claude Code in this situation. I'd just type `rclone copy <source> .`.
Right, I see, so when there's an opportunity for a rant you get one specific, narrow meaning, discarding anything else, even if more relevant and sensible, and then you go off.
Maybe try Claude Code one day, then you'll recognise what that phrase was actually about.
All the best! You must need it with such attitude to life.
You literally made a bunch of things up and directly contradicted the statement you so vehemently defended. That's not "sensible," and pointing that out is very different from word lawyering. No amount of "trying Claude Code" will compensate for that.
Just calm down. You seem to be personally offended at the mere suggestion that Claude Code isn't a good fit for everything, or that it's not even more trustworthy than Google. That's just a fact, not a "rant." If you feel the impulse to throw a tantrum because of that, I genuinely urge you to revisit your relationship with your cloud subscription because it's definitely not healthy for you, or the people around you.
Yesno. Not fully because a functionality is not enabled yet.
It wouldn't be advised to buy the latest pixel now anyway, either get the previous one or wait a few months for Motorola Signature 27, where GrapheneOS will be first party OS, and not hated-by-the-vendor bolt-on.
If you insist on the latest pixel, go check the GrapheneOS discussion forum for all the details.
If only the Motorola Signature 27 had a headphone jack, so that I could listen to high quality music with my quality headphones.
Instead I have to buy the shitiest locked full of crapware android phone and hack it with an LLM to make it usable because apparently that's what I deserve for wanting a headphone jack.
DAC have been more than good enough since the maturation of mp3 players in the early 2000s. The smartphone has a DAC and amplifier for its various speakers already. Heck the computer inside usb-pd power converter in the phone is many times more hardware and work and EMI constraints to respect than a DAC + amplifier for a headphone output.
The DACs/amps you linked are bigger than the Sony mp3 player I had in 2004. It had two jacks and a user replaceable battery. And it was water resistant.
The DAC I specifically linked is the size of my index finger, but since you seem to be casually suggesting that the "shitiest locked full of crapware android phone" and PCs dac are comparable with the dedicated hires dac, maybe you don't really need a phone jack and your audiophile headphones :D
Funnily enough that xkcd was created because Debian actually had a hardcoded random variable (the variable should have been randomly generated) ... It was noticed when certs/pub keys for different websites were coming up the same... Mind you this was close to A quarter century ago ....
You've misremembered, but it's worth me re-explaining this because lots of people even at the time tended to describe the mistake incorrectly.
Here's how the famous "Debian Weak Keys" come into existence:
OpenSSL had two buffers we care about here for generating random keys, with associated code to mix from those buffers into the data that's going to finally be used to produce cryptographically random numbers, lets call these bufferA, bufferB and mixA, mixB
In some cases bufferA is intialized by reading data from somewhere, in other cases it was never initialized. So mixA is doing uninitialized reads in those other cases. OpenSSL is written in C and in principle reading uninitialized data is Undefined Behaviour in C, but in practice nothing terrible happened here, you'd probably get zeroes, in some cases maybe unrelated trash. However, tools for spotting UB in your C library kept flagging mixA, which read this uninitialized data, as a problem.
bufferB is always crucial, if this isn't used the numbers won't be very random at all. This data is always initialized. But mixB is very similar code to mixA, after all it is doing similar work.
OpenSSL had rejected work to "fix" the mixA uninitialized bug but a Debian developer decided that it was too annoying so they patched mixA out. If that had been the whole story nothing terrible happens and nobody would remember today. However since mixB is similar, that Debian developer asked the OpenSSL developer list hey, is it OK to patch out mixB too?
And the developers said it was OK. The result is that Debian shipped OpenSSL which did not actually generate truly random keys. There were some number (thousands?) likely and of those a handful were especially most likely to be picked, based on exactly how soon after system start you wanted to make some keys with OpenSSL.
Now, after this blew up those developers said they thought the question was about testing. And IIRC it was possible to look at the same email and, if you know mixB is crucial, you think obviously they just want to test that their change does what they expected, nobody would patch out mixB in production, that's crazy. But the developer who wrote the email intended a different meaning, they really did mean to patch out mixB and were asking if that's OK.
Thank you for that trip back into a very dark corner of my memory. I had almost forgotten the whole circus of it all; right about then i was working in the hardware 'nearly true RNG' and had this whole can of worms happen right in the middle of an otherwise working setup. What fun.
That's as clear an explanation about the situation as I have ever read. I don't know the occasion to need to explain it to anyone else will arise, but when it does... or I may use it as example of the consequences of shallow communication when serious outcomes may arise. (Ill be sure to credit the source 'tialaramex' on HN)
Train driver and signaller both believe they've reached the same understanding of the situation, but their understanding actually remains divergent, and the driver (plus a MOM) nearly gets killed as a result.
I believe the specific change was to remove this line of C in two places
MD_Update(&m,buf,j);
And the reason it was a security bug is that in one of those two places the variable buf has the precious entropy we wanted in it and so now we're not really getting random numbers.
I've seen this mentioned a few times over the last day or two, but it's not true.
The xkcd was 2007 [0], the Debian issue was 2008 [1].
It was used in pretty much every blogpost describing the Debian issue, but it wasn't created because of the Debian issue (unless they gave Randall an 8-month head-start before disclosing it).
(I don't mean this as a "well akshully" - but for me it's more impressive that it's a truism that keeps coming true, than if it was just a swipe at them in the first place)
There are fully planned and built cities, like around here so called "Garden Cities": Welwyn Garden City, Milton Keynes.
I've been in several and they actually feel okay to live in, to run errands, to shop.
It only sounds funny if it's cranked up to the extreme -- like abusive housing associations, a cancer growing on the corpse of the old communities which just wanted some quiet evenings and the bins to not be overflowing, but it can be done well.
The garden cities were merely planned in layout and after that have "normal" levels of planning control. It does make them a bit different but not in uncomfortable ways. Sometimes called "soulless", which really just means "new" - lack of feeling the connection to previous generations through heritage.
You'd need at least 150-200 kg payload to account for thinks like clothes and equipment ;) but indeed, the difference with the cost of purchasing, flying and servicing the helicopter are stark.
reply