I assume this is the same "problem". Most people (not the HN cohort) don't want to transfer "files", the abstraction of the file is either outdated for them or maybe even unnatural / unknown (younger generation).
They might want to transfer (a better word: share) photos/videos, documents, etc. And for those they use specific apps and "the cloud". No "files" (for the sake of files), and barely any hierarchy of (folders etc).
As long as the entity they want to share magically shows up on the another device or at the other person they want to share with, they are happy. They just skip two levels of abstraction ("this photo is a FILE and I will use USB to transfer it"). Maybe a far fetched analogy but this is why most of the drivers of an automatic don't really think about clutches and how the torque of the engine's output is converted.
At least this is my perception (outside the IT bubble)
I think I disagree with that. This "people don't want files, they want to share photos", to me, is what product people want to believe. The whole thing has been enforced on users and is self-reinforcing: of course if you don't show files to users, they will not know what a file is.
Sure, I may be in a photo gallery and I may want to share a few photos with a friend who may want those photos to be treated as photos (instead of going into a big "Downloads/" folder). But it doesn't mean, at all, that the concept of file has to disappear to the user. In fact the files still very much do exist on the system. Product people just assume users are stupid, IMHO.
And the thing is: this abstraction (not knowing what a file is) doesn't make it faster or more efficient. It just makes the user more dependent on their platform and apps. Look at backups: product people at Google/Apple will tell you "people don't want to backup their files, they want to pay us to make sure that they never lose an image". Conveniently, it means that people are 1) forced to pay them and 2) don't have control over their own files.
Maybe GenZ/alpha now are stuck with these abstractions because they never learned what a file was (for no reason other than being abused by product decisions), but older generations grew up with physical media. "I have a piece of paper, I have a book, I have a CD-ROM, and those are all different kinds of files that can go into different "boxes" that are called folders".
Files and folders are very natural. The reason people don't know about them is because we hide them and force them to pay for literally subpar experience.
Were you born with the knowledge that a video takes more space than a photo that takes more space than a text?
Or is it rather that you consider yourself one of the few people smart enough to memorise it? I find that very condescending.
I don't believe that one needs 3 postdocs to understand it. In fact, I do happen to have explained it quite a few times, and I don't remember anyone not understanding it.
Because we can't transfer easily transfer files between devices remotely, we had to get used to do it via apps. And so we didn't developed good, local files browsers (esp. for media) and companies invested in the cloud UI mostly because they could sell the storage and sharing capabilities. That was all unnecessary but we're used to that now to a point where sharing files is weird.
As a power user happily syncthinging all my files between all my devices, I'm sad because files is the easiest thing to share, organize, transfer, etc. I wish iOS supported this kind apps (full storage access!) as we could avoid the many, crazy, Alps specific workarounds just to share some stupid files.
And don't confuse the file itself (say, a pirated movie), the metadata (IMDb IDs) and the apps UI (Kodi!). Files is what we have, we should share files and let anyone pick the browser/apl they like for viewing, organizing…)
Don't get me wrong, I'm totally happy woth files. In fact, I'm sometimes a bit annoyed when certain apps' entities don't map to files either accidentally or to maintain the walled garden on purpose (I'm looking at you Google Photos, and the very cumbersome rclone connector to it).
On the other hand, I don't mind that full storage access is a "pain"; I don't even remember which apps I gave the permission to, and I would certainly be angry if my syncthinged files would be stolen by other app that went vicious.
All that said, as people don't think about their documents/photos/any other stuff in their homes as "filed items in folders", non-tech people also don't think about their digital items as such. And maybe this is alright, if the "file-ification" would have been so successful, better products would have emerged.
One of my great hate pet peeves with all smartphone and cloud apps is the "abstraction" and reliance on search. For me folders is quicker and less error prone, and as a bonus it saves on unneeded bandwidth (to load previews) and computing costs.
Also stop telling me I must use your one off "feature set" of sorting and ordering which either nobody uses or copies differently. The amount of square wheels (for me I must add, ymmv) reinvented is astonishing.
The worst is photos, because the search abstraction really breaks there. On modern iPhones, it's still a pain in the ass to organize photos in such a way where you can come back later and find them. I'm still in the "scroll through the timeline until you spot it" phase.
Machine Learning is making this better, but ideally albums or folders wouldn't be such a pain in the ass to actually use in day-to-day life.
Folders as an abstraction don't really make sense beyond documents, though.
If your music is stored in a folder hierarchy, and can, in principle, be located anywhere, how do you index it to provide a library view? How do you distinguish it from random audio files that just happen to be ID3 tagged, but which you don't want as part of your permanent music collection? How do you efficiently react to deletion events? What happens if you delete an entire artist's worth of music from your music app? Should it delete the files, or only the library entries? If it deletes files, what if (some of) that music was in a folder that didn't contain any other files? Should that folder be gone too, or should you be left with an empty folder or hierarchy? What if the folder also contained a .nfo, is it good UX if it deletes the music and just leaves the .nfo?
If the only tool you have is a computer, everything is a file. If you're a music lover and not a computer enthusiast, you tend to think about albums, artists and playlists, and that's how you want to view your music collection.
You index it with btrees just like everything else. You distinguish it by configuring which folders to watch. You react to events with inotify. You don't give your music app write permission to your library. It only needs to write its indexes and playlists. All of your other questions become irrelevant; you delete the files you mean to delete with your file manager. In practice, music is small and storage is cheap, so deleting seems like a weird use-case for an application dedicated to music. I still have files that have been migrating across computers for 25 years.
Your player scans your library and indexes/sorts it however you'd like. I think this is how basically every player with a library function works? Like jellyfin loads my library in the same structure I've had it for 20 years, and it gives me various ways to view by name, artist, release date, rating, etc. and builds search indexes. I just point it to the roots of my libraries.
I said it needs a place to write playlists (or write access to your playlist folder(s)).
I wouldn't do it this way, but there can be more than one folder containing the same file (hardlinks).
> Your player scans your library and indexes/sorts it however you'd like.
Which means the concepts of files and folders becomes immaterial. If a music player is only interfacing with a database of music metadata it doesn't matter how the bytes on disk are organized.
There's a reason there's been 30+ years of file systems trying to tack on database functionality (BeFS, WinFS, etc) or over the top metadata indexing (Spotlight, Lucene, etc) to file systems. The files and folders abstraction is not sufficient for non-technical users in many cases.
The music player isn't the only thing interfacing with those files. Backups do. Network file shares do. Pendrives, dedicated music players, and children's toys that can load music do. The player changes over the years (winamp, VLC, amarok, clementine, jellyfin, etc.). Sometimes "apps" go wonky and the only way to fix them is to "clear user data", which is opaque, and you'd rather control that/be more selective.
I don't really care how the player stores its metadata (the secondary indexes it makes after the scan), but I don't want it mucking with the original data, which I've had and will continue to have far longer than the player. Files in a known format (e.g. .flac) offer a standard, common interface for storing that data that's easy to organize and exchange across computers.
Google drive also shows what a world where people don't use folders looks like: I can never find documents at work without a link even when I have an idea of what I'm trying to search for. Folders at least push the user to do some organization. GDrive happily encourages you to do none.
Also, they want to use the same "abstraction" for "sharing photos with their friend when they're on holiday in another country" versus "sharing photos with that same friend when they just got back and are literally sitting next to each other."
People don't really internalize that those are two different use cases.
Yes there's Airdrop, but I think most people view it as more of a "discoverability" solution than a file sharing solution. If you met somebody you don't have a number for, "okay just Airdrop this to me" is much easier than doing the whole song and dance of adding them to contacts and sending them an iMessage or finding them on Whats App. Whether the actual file transfer part of Airdrop goes over the internet or over Bluetooth isn't something most people care about, as long as it can discover nearby devices and initiate a transfer to them, it's good enough.
I disagree. I find it condescending when techies say "the average user doesn't make the difference between sharing a file to a device next to them and sharing a file over the Internet".
Everybody, and I mean everybody is capable to understand that to connect their Bluetooth headset to their phone, they do it over Bluetooth. And that to connect to the Internet, they can either go over WiFi (which is "free") or cellular (which is less "free").
> People don't really internalize that those are two different use cases.
We actively keep them ignorant, and then we use their ignorance as a justification. I find it sad.
What if we said "People don't want to drive their car somewhere, they want to go from A to B. We should prevent them from learning how to drive so that they would have to pay for our taxis".
I don't get that. How do you expect to abandon the file layer on your OS? Do you plan on rewriting Windows, macOS, Linux, Android and iOS with a fundamentally new philosophy?
If not, then you're not abandoning the file layer at all. You're just preventing people from benefitting from it.
The file API might not, but all major filesystems implemented some kind off Metadata attributes, IIRC Microsoft was wanting to heavily rely on that for "user space" stuff (e.g. Users leveraging it for semantic information about their files)
Seems to me we very rapidly arrive at records or entities.
We see both these days in databases.
Entities show up in CAD and simulation. Records show up in business tools of various kinds.
All require a schema and serious dependencies flow from there.
In CAD, for example, the database schema can change quite dramatically from version to version of the same software tool. And all this makes writing plug in tools or anything really painful.
And forget exchanging native data between systems. STEP exists for that, and O God help you on a bigger project involving any old data
The thing about files is they are basically EASY.
And easy, when looking at where we are going, matters. A lot.
Files can exist on pretty much anything. Paper tape, mag tape, all sorts of media, up to advanced storage tech.
Databases are a different story.
I am not convinced we are anywhere rear being ready for that huge leap.
And I would normally say "forward" but on this?
Nope!
It would be a huge mess requiring we toss just about everything we have in use today
Bluetooth FTP was widely supported until ~2009. All Nokia phones and many flip phones had it. iPhone did not, AOSP technically did, but carrier phones often had it disabled, and it slowly disappeared.
Windows 11 still supports it, I think macOS too. Pairing is technically optional.
It does and I managed it recently. It was painful.
I had to pair, or at least I think I did. Was fetching a file. off a flip phone. Doing these things without "file" gets weird quick.
I also seem to recall an awesome Bluetooth control panel applet I used a few times in Windows XP.
At the time I had a pretty spiffy Moto flip phone. It could be the computer keyboard, handle audio play and record and more.
Pretty sure that all came from the phone driver. I do recall also using the computer in reverse the same way when the display was badly damaged. I could make phone calls, dialing with the computer and in general use the phone taped to the back of my laptop screen.
aw. it hurts my brain to think about those days somehow. An awesome panel must be BlueSoleil. There were Microsoft XP SP2 stack that were stable but featureless, Toshiba stack with (IIRC)SCMS-T DRM support, WIDCOMM stack that show up on search now but I had no experience with - apparently tied to specific dongles, and the IVT BlueSoleil stack with the orange sun floating against dark blue background.
BlueSoleil was by far the most feature complete, and, as far as my interests back then were concerned, required for Wiimote on Windows. It was (not really)available as trialware but interoperability wasn't guaranteed so you would have had to pull dongle lottery until you hit a product with reasonably stable build of BlueSoleil if you had in mind a specific task to do in Bluetooth.
Fun times... things do feel less robust these days. Software was much better tested back then.
Yeah that seems familiar. One night on business travel, I decided to just play with the setup and really thought highly of it all.
Then some years passed, I got a Blackberry Curve, then a Note 4 and by the time I looked back at Bluetooth. I HATED IT. Still do, though I am grudgingly working through basics, phone call, play audio, etc and the whole time looking at my still wire capable hardware thinking "not yet"
How does it not solve the problem? The data shows up on the other end. The fact that you don't agree with the implementation is a different thing, but it does solve the case.
For small files maybe. As shocking as it may seem, most Dropbox users just have the free version, with very limited space. Same for Google Drive or One Drive.
Dropbox is unavailable to huge populations. also sharing private bits with a cloud service should not be necessary to transfer files locally between devices. at least user level file encryption should become straightforward on a mobile device which it is not today.
This is an UX problem, not a technical problem. You could easily use Wifi to transfer files between devices quite fast, there's just no agreed upon open protocol for it. Afaik that's how AirDrop works.
But that doesn't need new peripherals, I could do that in my home WLAN network if they'd just install standard software for it on the phone (which you can fix by installing it from F-Droid etc.)
Transferring files between a phone and a computer was a real use case, but since wireless usb was "exactly like regular usb but no wires" it wasn't any easier to set up file transfer than regular usb (harder, actually, since you had to do the wireless bonding), and wired usb would charge your phone battery while the files transferred whereas wireless usb would drain it.
There's no formal standard, but I keep seeing this complaint from people who just haven't installed syncthing. At this point it's not inexistence but mere ignorance
Which is also way way easier to do than all the existing solutions: create a folder on the computer, add the computer to the phone, share the folder with the phone. Anything you want to share goes in the folder.
Airdrop works. Ok, it's platform bound, but I'm sure it could be ported.
It's not such a big thing, though. I hardly use it, and young people don't seem to use it either. The stuff on their phone and laptop seem separate worlds, just like mine are. Might be because they don't know about it, though.
Because we keep them ignorant. We make sure they depend on our apps that they have to pay for. You wouldn't want them to know how to download music/movies without going through our paid streaming platforms, would you?
Hell, copy and paste works between iphone and MacOS if you've got the same icloud logged into both. Airplay is too cumbersome has been supplanted by long hold -> copy; ctrl-v, and the reverse. Works for images as well.
That requires having an account on the other machine. What's missing is anonymous scp, where the other side just opens up a directory, and you can copy into it. One can build something like this with rsyncd, but it's not a pretty shell one-liner to get it going and it still requires both devices to be on the same network.
What I responded to was "wirelessly transferring files between a phone and a computer", assuming that I am the user at both ends of the transfer.
If I want to share something with someone else, there's a "File Sharing" section in phone's settings that enables anonymous WebDAV sharing, and it works fine too. There's Bluetooth OBEX too, but that one's fiddly.
Wirelessly transferring files between a phone and a computer seems like a big use case. Still no easy standard way of doing it.