TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

The Future Needs Files

168 点作者 polm23超过 3 年前

13 条评论

superbaconman超过 3 年前
This is a big complaint I have about iOS. One day I get a notification telling me that my cloud drive is almost out of space so I go to clean it out using the finder, and I find like 4 empty folders. An hour later I realize I have a bunch of photos synced, but I they're only viewable/removable through the photos app (somehow this includes images that I downloaded). It feels like such a poorly designed system.
评论 #28408570 未加载
评论 #28407994 未加载
评论 #28407790 未加载
评论 #28405508 未加载
theamk超过 3 年前
Some counterpoints:<p>(1) Just &quot;files&quot; are not going to save you -- they must also be in the standard format. It may be pretty simple for text-only notes with no support for formatting, but anything more advanced gets complex fast, <i>especially</i> if you expect files to be editable.<p>(&quot;Editable&quot; is the worst, actually.. Imagine a pen-based note-taking app which stores data as PDF in user-accessible location... users would expect to be able to drop any random PDF and have it show up and be editable. This will make the code immensely more complex compared to simple proprietary format)<p>(2) The file interface is pretty limited (no easy way to detect new files, can only query by name), so you need indexes and secondary metadata. You might need a non-trivial amount of metadata in app-specific format for advanced functionality, like &quot;get past version&quot; or &quot;find similar objects&quot;.<p>If you are allowing user to mess with your files, this gets much harder -- you now need to be able to re-scan the whole folder, and try to infer renames. This is certainly possible -- many old-school MP3 managers did this -- but it is a significant additional effort.<p>(3) A lot of times, it is easier to provide alternate mechanisms rather than trying to shoehorn the data model into filesystem (this applies less to mobile, and more to other non-file-based apps), for example:<p>- The (cloud based) note-taking service I use offer &quot;export&quot; option -- your notes are stored in whatever cloud database, but there is a 2-click way to download entire thing as .zip full of text + opml files.<p>- There are also APIs -- the same service offers API to download&#x2F;upload notes. I run a small script from crontab which downloads all the nodes periodically to my computer.<p>- Local only: &quot;git&quot; does not expose past revision as files -- you use various git commands to see that data.
评论 #28406606 未加载
zepto超过 3 年前
This is a weak analysis. There are large numbers of ‘shoebox’ style applications which pre-date iOS, and they exist on every platform. It’s a mistake to attribute their existence to iOS.<p>The point of a shoebox app is decouple the user model of organization of data from the file system model <i>even as files are used for storage</i>.<p>This is done because the filesystem user model is inadequate or inappropriate, or because the storage model is expected to change.<p>iOS allows apps to expose their data as files within the Files app <i>without</i> requiring them to expose the underlying files themselves.<p>A good example of this is Quip, which is a collaborative document editor. All of Quip’s data is stored in their online database, but it is also exposed through the files app as a set of PDFs.<p>Notes could expose a filesystem style view if Apple prioritized it. Of course then we’d have the issue of file format versioning etc. to deal with. If I were them I wouldn’t be rushing to make that trade-off.
评论 #28396923 未加载
rektide超过 3 年前
There&#x27;s almost no cross-system paradigms that have survived the cloudification of software. Each app builds it&#x27;s own intra-verse of ideas, it&#x27;s own tools. The only thing left that has any meaning is the URL. Which I for one like, but it feels deeply insufficient.<p>This article is great. Great topic, great coverage, good range, solid points. Thanks.
评论 #28399786 未加载
评论 #28407191 未加载
sbazerque超过 3 年前
I agree with the author on the merits of the file abstraction, but I think the concept should be updated for networked devices. We need file formats that support both offline usage and seamless sync over the network.<p>For example, here I use a merkle DAG-based file format to represent CRDT-like types:<p><a href="https:&#x2F;&#x2F;www.hyperhyperspace.org" rel="nofollow">https:&#x2F;&#x2F;www.hyperhyperspace.org</a><p>The resulting abstraction can be universally looked up using a hash (or short sequence of words), can be modified offline and synchronized flawlessly. It&#x27;s still WIP (for example, you still can&#x27;t export it to an actual file, hehe).
评论 #28409240 未加载
travisgriggs超过 3 年前
It’s interesting to me that the focus of this analysis is handhelds. But what about all the web apps out there that use SQL databases to rowify my data?<p>Can&#x2F;should one argue that web apps should be backed by highly indexable&#x2F;searchable file systems so that when I want to depart a platform I can just ask the backend for my files?
评论 #28405430 未加载
评论 #28408476 未加载
gumby超过 3 年前
The terrible culture of app-centric (rather than document-centric) computing goes back to the 1980s. iOS (and as a result android) merely accelerated the trend.
评论 #28408071 未加载
ape4超过 3 年前
It seems each new release of Android makes it harder for apps to access boring old files. Seems to be on purpose.
grandpa_on_lawn超过 3 年前
To paraphrase an old saying: how do &quot;files&quot; help me go viral on TikTok?
streamofdigits超过 3 年前
Seems to me the focus on &quot;Files&quot; is more of an excuse to discuss the broader data architecture of mobile devices, in particular how they store and make accessible private data to ML type applications.<p>Not sure they are (or ever will be) the core issue preventing this future. Linux desktops are file based, in principle one could envisage intelligent open souce PIM applications that integrate all the personal data securely and privately, but nothing of the sort exists...
skybrian超过 3 年前
On the other hand, file format compatibility is hard to get right and results in ugly hacks and subtle breakage when multiple apps want to extend a standard. Steve Wittens has a good blog post about this:<p><a href="http:&#x2F;&#x2F;acko.net&#x2F;blog&#x2F;on-variance-and-extensibility&#x2F;" rel="nofollow">http:&#x2F;&#x2F;acko.net&#x2F;blog&#x2F;on-variance-and-extensibility&#x2F;</a>
reidjs超过 3 年前
If you’re on an iPhone I recommend iA writer which allows you to save .md or .txt files and sync to your other devices with iCloud or Dropbox<p><a href="https:&#x2F;&#x2F;apps.apple.com&#x2F;us&#x2F;app&#x2F;ia-writer&#x2F;id775737172" rel="nofollow">https:&#x2F;&#x2F;apps.apple.com&#x2F;us&#x2F;app&#x2F;ia-writer&#x2F;id775737172</a>
jofer超过 3 年前
I never would have believed that &quot;filesystems are useful and good for organizing information&quot; was a controversial statement until last year when I worked for a company where the CEO insisted that &quot;files and folders are ruining people&#x27;s minds&quot; and started a very serious push to avoid anyone using a local filesystem in any way.<p>In principle, sure, centralize data management. It&#x27;s important. I get it. Messy shared filesystems aren&#x27;t a great way of archiving data. But at the same time, they&#x27;re a good solution for quickly producing and using data.<p>The context was around specialized desktop application for technical users (desktop GIS). Yes, you can stream data, and yes, database connections are very much a thing, but that doesn&#x27;t get around the simple fact that the UIs on everything are set up for local file access. Furthermore, the other applications used alongside this also expect (and in many cases, only accept) local files. 90% of the expensive software you&#x27;re paying for (or the open solutions too) can&#x27;t talk to that nice fancy internal-only API you set up to &quot;replace filesystems&quot;. In practice, folks are going to wind up with local files anyway, which means you wind up with multiple different copies of the data, which was the whole thing you were trying to avoid.<p>Also, users are _mostly_ creating new data and not just consuming existing data. The whole point is to have a gui toolbox for processing data and creating new datasets. At a deep level, that&#x27;s best solved by local files for this use case. (i.e. the formats you need to use for interoperability are meant to be updated efficiently as local files. You can stream them, but not easily update them.) Yes, it&#x27;s possible to have centralized data stores, but they often wind up being a SMB&#x2F;NFS&#x2F;etc share because you need to open the data in multiple applications and local files _are_ the interoperability standards. Embrace shared filesystems where they make sense. They&#x27;re not the enemy.<p>Next is hierarchy. Folders are a _great_ system for organizing temporary ad-hoc work. They&#x27;re also a pretty good system for organizing longer-lived structures. Pushing things into a limited database schema or tagging structure actually makes things harder to find than a &quot;working folder&quot; approach, as it&#x27;s difficult to group unrelated data together. Sure, you can tag things for grouping, but that generally loses hierarchy. You can reproduce hierarchy with nested tags, but then you&#x27;re back to representing things as folders. That representation is _useful_ in many cases and isn&#x27;t a bad thing.<p>In short, filesystems are good for interoperability on the desktop and desktop workflows are still very necessary for many things. Hierarchical organization is useful, and insisting on dropping it comes with a cost. &quot;Shoebox&quot; &#x2F; no-file solutions are good for some cases, but not for all. Be _very_ careful about trying to force solutions where they don&#x27;t fit.