Hacker News Reader

Comment by kmarc | Hacker News Reader

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)

View on HN

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.

> is what product people want to believe

It's quite clear what you never had to explain why 'only looking at a pictures/photos on the Internet' wasted the mobile traffic.

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.

Folder / Directory

I most frequently use the latter, directory when I am talking files and filesystems.

Most people return that with "folder", and I am sure that has to with my learning about these things happening where "directory" was the norm.

I have been educating people about files when I bump into ones that do not know much. The abuses are real and growing. Nice comment.

I believe in the opposite.

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.

> and barely any hierarchy of (folders etc).

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.

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.

What if I want to look at a list of composers, but the folder structure is by artist?

What about playlists?

The limitation of the folder is that there’s only one.

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.

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.

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 want to add something to this: abandoning the fire layer allows for richer custom flows (which to many are arguably worse)

For example the file API does not allow a clean, uniform, and reliable way to associate a resource with some metadata

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)

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.

If we don't have files, then what?

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

Reply on news.ycombinator.com