Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Android and iPhone users can now share files, starting with the Pixel 10

blog.google

Post reply on HN
Print view View original

561–570 of 585 posts

Re: Android and iPhone users can now share files, starting with the Pixel 10

#561

Post by raw_anon_1111 »

rpdillon wrote: post #552
raw_anon_1111 wrote: post #550

Earlier quoted context omitted.

Does SyncThing automatically back up everything ? Settings, in app data, icon positions, bookmarks, messages, and browsing history? If you through your phone in the ocean and gestured on another one, would your new phone look just like your old one? And it’s been discontinued for Android…. https://forum.syncthing.net/t/discontinuing-syncthing-androi...

We're having different conversations.

How so? I want my backups to actually backup everything. No one cares about backups - they care about restores as the old saying goes.

If I can’t in fact throw my phone in the ocean when I’m away from my computer, go buy another phone, log in and everything is automatically restored, it’s a poor solution

Re: Android and iPhone users can now share files, starting with the Pixel 10

#562

Post by kccqzy »

1718627440 wrote: post #557
kccqzy wrote: post #490

Earlier quoted context omitted.

When you create a ZIP, the extended attributes are saved to separate files. When you copy them to a FAT filesystem they are also saved to separate files.

Interesting, but now this information is no longer attached to the original file and you need to manually include it, when distributing the file. Also it is now kind of obvious, that there is not only the file itself in the ZIP file.

It’s not obvious if you are only using macOS, because macOS hides all of these extra files it creates. It’s only obvious if you use Windows or Linux. But of courses the chances of a typical macOS user also using Windows or Linux is very low.

Re: Android and iPhone users can now share files, starting with the Pixel 10

#563

Post by pxc »

1718627440 wrote: post #558
pxc wrote: post #503

Earlier quoted context omitted.

/run isn't for¹ application data, and it's also not persistent (it's often on a tmpfs). But sure, an OS could in theory use something like /var/cache/ instead of ~/.local/cache. I'm not aware of anything that does, though. ---- https://specifications.freedesktop.org/fhs/latest/run.html

You are right. I see a lot of applications putting stuff into /var/run/user/ /, but this is mostly ephemeral runtime data, notably sockets. And of course systemd has service units there, which don't seem temporary at all, but it's systemd, so whatever... . The correct way for what I intend would be /var/lib/user/ /, but yes this does not exist on my host. But I honestly don't see why non-ephemeral per user data shoul…

I think the systemd units in /run are indeed ephemeral, and indicate units that are active. If they have permanent counterparts (some units, like transient timer units, don't have them), you'll find them under /etc/systemd or /lib/systemd for system units and ~/.local/share/systemd or ~/.config/systemd for user units.

> But I honestly don't see why non-ephemeral per user data shouldn't be put into /home

I think I agree— as long as the conventions are clear, I think it's reasonable to have some hidden dirs under $HOME set aside for configuration and cache and so on.

Maybe there's value in exposing a single directory as the root of a sandbox for user files, so users have to go farther out of their way to screw things up, especially depending on your audience. Maybe a decade from now Linux desktops will have something like this, because most apps will run sandboxed in Flatpak, unable to write to the root of $HOME. (Idrk how that's organized, though— maybe apps are just allowed to edit "their" dotfiles without modifying their location.)

But I'm not sure that obscuring configuration data's place in the filesystem in that way is really desirable or necessary. I doubt most users inspect or think about hidden directories on Unix-likes unless they're looking for them anyway.

Re: Android and iPhone users can now share files, starting with the Pixel 10

#564

Post by varenc »

dataflow wrote: post #553
varenc wrote: post #318

Earlier quoted context omitted.

AirDrop compatible Quick Share isn't even going over the local network. It create an adhoc device-to-device wireless connection and the files are sent that way. So the two phones don't even need to be on wifi or be on the same network at all. The local network isn't involved. Given this, I think there's minimal risk of it sending files over the internet.

> It create an adhoc device-to-device wireless connection and the files are sent that way. So the two phones don't even need to be on wifi or be on the same network at all. Isn't that just Wi-Fi Direct? Which I understand establishes a separate, dedicated temporary network for that task over Wi-Fi, with the two devices being the only ones connected to it? Isn't that still two machines on the same network via Wi-Fi, m…

It's "WiFi-Aware" which seems like a related standard. I think the difference is it handles the discovery and secure connection part, then once established its like WiFi-Direct. Because of this I think it's unlikely.

And Apple devices can do this while simultaneously connected to another wifi network. Maybe Android does too. Which would make your concern more possible if it does this too!

Re: Android and iPhone users can now share files, starting with the Pixel 10

#565

Post by brokenmachine »

vovavili wrote: post #438
brokenmachine wrote: post #350

Earlier quoted context omitted.

The problem is that because fleecing dummies is so profitable, it encourages the same scummy behavior by other companies.

Calling an extremely broad user segment dummies is unreasonably condescending.

Did I say they were all dummies?

You said there's nothing wrong with how Apple exploits their target market.

Scummy behavior being normalized is what's wrong with it.

Re: Android and iPhone users can now share files, starting with the Pixel 10

#566

Post by SchemaLoad »

padraic7a wrote: post #393
SchemaLoad wrote: post #331

Earlier quoted context omitted.

What's sad is what largely replaced device to device transfers was just messaging apps. But messaging apps compress media horribly. iMessage isn't so bad, but send a photo through almost anything else and all meta data is stripped, and the image resolution and bitrate are the absolute bare minimum to look ok on a phone. But try to print it and it will be horrible.

Stripping the metadata on a photo is probably a feature though. For privacy reasons the default should most likely be that location, device info etc are taken out of photos that might go viral or be shared beyond what the original user intended.

It depends, I do wish it was an option that the user can pick from. Quite often you get sent photos of you or an event you were at and you'd like the metadata to be preserved. For posting on social media, sure it's best to strip it.

Re: Android and iPhone users can now share files, starting with the Pixel 10

#567

Post by SchemaLoad »

1718627440 wrote: post #558
pxc wrote: post #503

Earlier quoted context omitted.

/run isn't for¹ application data, and it's also not persistent (it's often on a tmpfs). But sure, an OS could in theory use something like /var/cache/ instead of ~/.local/cache. I'm not aware of anything that does, though. ---- https://specifications.freedesktop.org/fhs/latest/run.html

You are right. I see a lot of applications putting stuff into /var/run/user/ /, but this is mostly ephemeral runtime data, notably sockets. And of course systemd has service units there, which don't seem temporary at all, but it's systemd, so whatever... . The correct way for what I intend would be /var/lib/user/ /, but yes this does not exist on my host. But I honestly don't see why non-ephemeral per user data shoul…

The average user does not see things like app config files, cache data, etc as their own files. The current /home has so much absolute junk that it's easy to not know where your stuff is. "Real" files to a normal user are .docx, photos, downloaded files, etc. Not auto generated configs.

There ideally should be some separation between your actual documents and system utility stuff. I guess this has mostly happen already with real files sitting in cloud storage. With local storage just being replacable.

Re: Android and iPhone users can now share files, starting with the Pixel 10

#568

Post by delta_p_delta_x »

josephg wrote: post #183
layer8 wrote: post #146

This is based on Wi-Fi Aware: https://en.wikipedia.org/wiki/Wi-Fi_Alliance#Wi-Fi_Aware Some background: https://www.ditto.com/blog/cross-platform-p2p-wi-fi-how-the-... On the Apple side, this was prompted by the EU Digital Markets Act: https://digital-markets-act.ec.europa.eu/questions-and-answe...

This is great! I notice that’s on the ditto blog. I can see why the ditto developers are watching with keen eyes! I have a modern digital camera complete with wifi and bluetooth. There’s an app that lets me connect the camera to my iPhone for monitoring, remote shooting and copying photos. Very useful! But right now the only way for the camera to connect to my phone is through some super complicated song and dance, i…

> he only way for the camera to connect to my phone is through some super complicated song and dance, involving my phone requesting a connection over Bluetooth, then the camera running a wifi access point that my phone connects to (during which time my phone disconnects from my home wifi)

Sounds like a Nikon mirrorless. I have a Z6iii, and I am constantly confused with the networking setup. There are something like three duplicated menus, all with very similar functionality.

Re: Android and iPhone users can now share files, starting with the Pixel 10

#570

Post by pxc »

SchemaLoad wrote: post #567
1718627440 wrote: post #558

Earlier quoted context omitted.

You are right. I see a lot of applications putting stuff into /var/run/user/ /, but this is mostly ephemeral runtime data, notably sockets. And of course systemd has service units there, which don't seem temporary at all, but it's systemd, so whatever... . The correct way for what I intend would be /var/lib/user/ /, but yes this does not exist on my host. But I honestly don't see why non-ephemeral per user data shoul…

The average user does not see things like app config files, cache data, etc as their own files. The current /home has so much absolute junk that it's easy to not know where your stuff is. "Real" files to a normal user are .docx, photos, downloaded files, etc. Not auto generated configs. There ideally should be some separation between your actual documents and system utility stuff. I guess this has mostly happen alrea…

> .docx

goes in ~/Documents

> photos

go in ~/Pictures

> downloads

go in ~/Downloads

> Not auto generated configs.

No Linux applications ever put configuration data in any of the aforementioned locations...

> it's easy to not know where your stuff is.

?????

Post reply on HN