There is user access, but app access is becoming scarce.
An app can ask you, as user, to pick a file for reading/writing/creation, and it receives access to something very much like a file, but the app isn't even permitted to know whether that's a file on the local device or an on-demand download/upload by another app.
> So is this to help protect apps from each other? And/or to protect users from malicious apps?
One angle is it prevents apps from scanning your local storage for files and stealing them.
Another angle is that it blurs the line between cloud and local so that storing data on cloud services gets treated the same as local data. If you happen to own said cloud storage services (cough Google cough) then that direction aligns with your corporate interests.
Not being concerned about where a file comes from sounds like a convenience to developers. It's like a file repository. I don't know why that implies Google is scheming to further integrate their cloud services.
It's not a convenience to developers, it's extra complexity. It's convenient for companies though, because it makes implementing cloud-centric business models easier. It's a problem for users, because they no longer have clue where the data is stored or how to find it beyond the app that claims to own it.
Protecting users from malicious apps seems to be the main thing.
I think you can manage files even without rooting. I plugged a phone (XZ1C, Android 9) into USB now, the computer offered to open the phone's storage, 2-3 clicks later and I see the photos that are stored on the phone.
Well considering that Android doesn't include a respectable file-browser built-in and so you have to do that through apps, that functionally means user access too.
Not OP but I like ES File Explorer. It perhaps follows a desktop FM form to closely, but works for me when I need to navigate the Android file system.
Edit: There's a load of suggestions downthread, I think I might be on an older version of ES, maybe pihole is blocking some of the ads others are complaining of.
Es was the best for awhile, but it's bloated and has ads now. I switched to Solid Explorer and it works great for me, nice UI and pretty quick. No complaints so far.
That seems pretty reasonable to me honestly given the whole mindset behind Android. Why would the average user even care about exploring the filesystem? And if you're a poweruser who really wants to have low level access then you can just root your device and run whatever you want on it.
Regardless of whether you think it's good or bad design, at least it's consistent IMO.
This sounds very much like the model Google uses in its Fuschia operating system, where there is no access to the filesystem per se, but handles are passed around, that allow writing in a folder or a file, with various permissions attached to that handle.
> and it receives access to something very much like a file, but the app isn't even permitted to know whether that's a file on the local device or an on-demand download/upload by another app
... and which is also completely unsuitable for content that implicitly depends on multiple files, e.g. locally stored HTML files: For the case where an app is launched because you wanted to view a particular file, you'll only get access to that "something very much like a file" for that exact file only, but you (respectively your browser) cannot access any other associated files that might be required (images, style sheets, scripts and whatnot) that way, and neither would navigation among separate files stored locally work.
That is part of the problem with this API its a pretty confusing choice. It technically means you give access to the entire SD card if you have it set to external card mode.
However, there is a setting to use SDCards as a partition extension and it appears as extra 'internal' storage space.
You could never access other app's internal files with this api. IMO this is a good change. This pattern only made sense when smart phones were simply nice camera phones with email.
What is the rationale behind abandoning the filesystem? Filesystems have served well on multiuser systems for decades but for some reason have fallen into disfavor.
Please don't repeat this myth. It's simply not true.
Every normal user can understand hierarchy -- shoeboxes in closets in rooms in houses in neighborhoods in cities. The human mind orders things in hierarchies effortlessly. It's just incorrect to claim otherwise.
The only thing users sometimes can't understand are badly designed user interfaces for exposing and navigating a hierarchy.
Humans might be able to understand hierarchy, and even apply it to physical objects in their possession sometimes, but looking at the filesystem of the average computer user would eliminate any notions you have that average users can actually maintain their own filesystems, or have any desire to.
Just go and do it instead of performing bullshit A/B tests and copying whatever lowest-common-denominator solution your competitors invented.
Regular users don't have context for technology, they scoop up whatever companies offer on the market. If everyone gravitates towards the same crappy solutions, most users won't complain, because they can't or don't want to imagine how things could be made better.
Users are wrong, and more importantly, lazy. No non-geek users actually want to spend their time organizing all their files into a well-thought-out hierarchical directory structure. Even worse, now users have been trained that it's simply not necessary, because "I can just search for whatever I'm looking for".
The irony. Anybody with basic knowledge of CS (ie a geek user) should grok that there is no such thing as a “well-thought” hierarchy. This is the very reason relational databases exist.
And for desktop and phone purposes, search is popular because it works damn well.
>And for desktop and phone purposes, search is popular because it works damn well.
It works well, until it doesn't. It's especially bad if you don't remember exactly what you're looking for; this is when a decent hierarchy is really useful. And yes, hierarchies have problems, which is why RDBMSs took over from the older hierarchical DBs which were used before that (such as on the Apollo program), but just throwing everything into a single directory and hoping file metadata and search will replace it all is wishful thinking.
In particular, search tend to be buggy, and if you have no reference hierarchy that you know shows you unfiltered results, you have no basis to trust that the results of your search query are accurate. This is no 1. reason I rarely ever use search on Android or Windows. I don't trust it.
this reminds me of the time that I helped my dad migrate his data to a new imac. with somewhat low expectations, I asked him if he knew where all his important documents were on disk. to my surprise he said confidently "sure I do!". he then opened the "All My Files" link in finder. I guess in a certain sense he wasn't wrong, but I still had to spend hours disentangling the files he actually wanted from thousands of random temp files and downloads. I made him get an external drive to clone the old drive anyway, and every so often I would have to help him find something that we had missed in the first pass.
I remember wondering at the time: do windows and mac not do enough to help users organize their files, or are the cute little My Documents and Pictures folders that obscure the underlying filesystem already too much?
A big part of that is the fact programs tend to spew their files haphazardly through Program Files/Program Data/Appdata/Documents/etc. I would be confused too with a physical hierarchical system if I had a robot that would randomly put the fruit in the closet shoeboxes next to a pile of batteries and toothpaste.
There is a fundamental impedance mismatch between what hierarchies facilitate and how users think of their files. Users think of their files as having concepts associated with them. e.g. "this file is a photo, about my vacation, and is about scuba" or "this file is a book, about scuba"
The user may attempt to express the numerous concepts they associate with their files in terms of a hierarchy, but chances are good they will fail miserably because hierarchies simply aren't up for the task of organizing even moderately diverse data. Is 'vacation' a subset of 'photos', with 'scuba' being a subset of 'vacation'? Where then does their scuba book go? Is the 'scuba' sub-directory something they must create twice, once under 'vacation' and once under 'books'? Inevitably some concepts get duplicated sub-directories across the system, or the user settles on under-organization. This is because hierarchy isn't up to the task of organizing files in the way humans think about files.
The answer of course is some form of file tagging, so that 'scuba' can be a single distinct group that overlaps with both 'books' and 'vacation' and 'photos', but isn't a strict subset of any of those.
> The answer of course is some form of file tagging, so that 'scuba' can be a single distinct group that overlaps with both 'books' and 'vacation' and 'photos', but isn't a strict subset of any of those.
But that is separate from what file paths are for, which is essentially a semantically meaningful unique identifier. If you want to take a photo with the camera app, crop it with the image editor app, then attach it to an email with the email app, you shouldn't have to search through your photos again the second two times to re-find the one you're already working on. There ought to be something equivalent to copying the file path to the clipboard so that you can reference the file you're already working with in another app.
> "But that is separate from what file paths are for"
This is close to my core point. File paths and/or file hierarchies are not good for file organization. They have been pressed into this role for historic reasons and out of inertia.
Papering over the problems of file hierarchies by implementing a good copy-paste system is not a good solution to the fundamental problem. It alleviates some problems, but not all. You can conceivably copy-paste a file you've been working on in one app into another, but what if you want to retrieve a file you last interacted with a year ago? How will you find that file?
Under the file hierarchy scheme, in order to retrieve an old file the user must remember the idiosyncrasies of the hierarchy they created ages ago, with many concepts invariably being split into gods know how many subdirectories, OR nearly all of their files sitting in a small handful of directories, unorganized, with little more than the file name to help retrieve the desired file. These are both poor states of affairs. They require the user to store too much extraneous state about the system in their head in order to have any chance of efficiently finding the files they're looking for.
Modern systems have begun to improve on this state of affairs by implementing file searching capabilities that function more like internet search engines than traditional hierarchical directory explorers. In theory the user may be able to simply search "scuba" and the black box file search system may use a variety of methods for pulling up a list of files from numerous different subdirectories it believes to be scuba related. Perhaps it pulls in both /vacations/2017/scuba/neat-fish.jpg and /books/scuba/how-to-scuba.epub because both have the string "scuba" in their path. Or perhaps there is some exotic shit going on behind the scenes and an image classifier was previously used to determine the presence of scuba gear in /Pictures/1002389943-984983-198395.jpg This sort of file search engine is fundamentally an imperfect file tagging system. The tagging in this case is being done automatically in a variety of ways the user may or may not be aware of and understand, and may or may not be able to consciously influence and exploit.
Let's take a step back for a moment and define the problem:
In the mind of the user, there exists a many-to-many mapping between files and concepts. When a user is thinking of a particular file, they have in mind a set of traits about that file. (For example, the user might be thinking of "that picture I took of a strange fish while scuba diving on vacation." The concepts associated with that file might be picture, fish, scuba, vacation.)
How do we get that mapping out of the user's head and into the computer, such that it can be used by the computer to retrieve the files a user desires when thinking about a particular set of concepts?
That's not yet a question with a definite answer. Automatic tagging of files with concepts the user is anticipated to have should certainly play a role. Image classification is heavy, and therefore has privacy implications since that sort of thing is virtually always offloaded to some corporate server, but when it works well it's great. There are easy sources for automatic tags as well, such as extracting terms out of the file path, or extracting date ranges or even geolocation out of the file metadata. These are great, but typically prove insufficient on their own. Asking the user to manually tag their files with the concepts they associate each file with gets you a very high quality many-to-many mapping between files and concepts, but that is manually intensive. Notoriously so. One solution is to amortize it; during file creation ask the user to tag the file instead of naming the file. That's okay, but still not great. The user might be snapping 10 photos...
> You can conceivably copy-paste a file you've been working on in one app into another, but what if you want to retrieve a file you last interacted with a year ago? How will you find that file?
With searchable tags, or whatever other thing you can come up with which is better than trying to remember a file path. But that doesn't mean you should get rid of file paths, because they're each good for different things and there is no reason you can't have both.
Here's another example. On a desktop you can open a static web page from a local .html file along with all the associated content. You'll have a directory containing an HTML file, maybe some associated .png, .gif, .webm or .js files and so on. A complicated one may have its own hierarchy because it's useful within the context of that document. Then that HTML file is going to have the names of the other files in it, including their relative paths if they're in subdirectories. The same thing can happen with InDesign documents or any other composite document like that.
Now how does the user find that HTML file a year later? Using some kind of tags or search function. But the way the HTML file then finds its associated pictures/scripts/videos is using something like filesystem paths. The alternative would be to combine them together into some kind of tarball, which is what some things do (like PDF), but then that's worse -- how do you edit a photo which is embedded in a PDF? Your average image editor will either not support it or will be inclined to do something horrible like rasterize the whole PDF first.
As I've detailed here (https://news.ycombinator.com/item?id=19523901), the idea is not to remove the traditional hierarchical file system from the low level, but rather to remove trace of it from nearly all human interaction. At the least, interaction with it should be opt-in, not opt-out.
You're touching on a broader subject than file organization though, and that is humanist software design. Your static web page example is a good example. That's not humanist software design, it's design that serves the computer. When you save a web page you get an html file and a directory next to it that contains the images, css, etc of that webpage. The user is now burdened with keeping that html file and resource directory next to each other for the rest of the lifespan of that [meta-]file.
Consider instead the epub format. It too is one or more html files with images, css, etc. However unlike the traditional local static copy of a web page, all of those files are zipped together and stored as a single file (an epub is a glorified zip file with a special file extension. You can extract them with `unzip`.) This unburdens the user; they no longer have to worry about keeping those files next to each other when copying it, sending it to other people, etc. Epubs are humanist design (and not only for this reason, but I'll save that for another discussion.)
Of course inside that epub is a hierarchy of files. And that's fine. A hierarchy of files serves the ebook reader well. While strict hierarchies are poor for user interaction, they're great for software. The details of a file format need not be humanist because the user is not meant to pick it apart. Of course there may be perfectly valid and common use-cases for the user to pick it apart, to pull images out of it for instance. Software that facilitates pulling data out of documents, into a format that is generally useful to the user, is humanist. Consider your common desktop web browser for instance. It allows the user to easily pull an image out of a webpage by right clicking on it and saving it, or perhaps dragging the image out of the browser onto their desktop, or similar modes of interaction. The user needn't save the entire webpage, then poke through a directory filled with numerous files looking for the image they wanted. (At least, not unless the website and browser are conspiring to behave in a manner that is hostile to the user, for example by blocking right clicking....)
PDFs and PDF readers are shoddy in numerous ways of course, and strict hierarchical file management has done little to alleviate that.
> the idea is not to remove the traditional hierarchical file system from the low level, but rather to remove trace of it from nearly all human interaction.
But that's the issue. You can make it easier to use tags, you can make it so that they are what most people use most of the time, but you still want everything to be able to use paths, in a way which is still as universal and intuitive as possible, so that it still works properly everywhere when you do have a good reason to use them instead.
> Consider instead the epub format. It too is one or more html files with images, css, etc. However unlike the traditional local static copy of a web page, all of those files are zipped together and stored as a single file (an epub is a glorified zip file with a special file extension. You can extract them with `unzip`.)
Here's something even better -- what macOS does with applications. You look in /Applications and see a bunch of programs. Those are really directories with the application's files in them, whose names are the names you see but with a .app extension. If you click on one, you don't see what's in the directory, you cause the application to open. But you still can see what's in there, by using the actual path with anything that accepts file paths, and that is still useful. Because sometimes there is a .plist file in there or something else you want to modify, or you just want to see what's really there.
This is better than a zip file because it's still native. You get the behavior you want, but if you want to see or modify what's in there, you don't need to use a special program or go through the extra steps to unzip the file and zip it again, you just access it using the real path. Windows at one point did somewhat the opposite and exposed the contents of .zip files as folders, but that doesn't seem to work as well, e.g. modifications are not permitted or are inefficient or have other issues because you have to repack the whole file with every write.
The way MacOS handles Applications is indeed humanist, but there is nothing about that user interface that intrinsically relies on strict file hierarchies. Furthermore, the implementation of it isn't generalized. The substance of what I think you're getting at is record-oriented files systems, which I consider orthogonal to the matter of tagging vs strict hierarchies. With a record-oriented files system, files are no longer seen by the OS as mere byte streams, but actually have meaningful structure. It needn't be implemented carelessly like Windows with it's zip support in Explorer.
It's a very compelling idea, but as I said, orthogonal to the matter of hierarchies or tagging. Say for instance you want to edit the .plist file of Blender.app. Where is Blender.app? Probably at /Applications/Blender.app but maybe it's in /Users/zrm/Applications/Blender.app To dive into that file/directory, you must first find it. How the user is meant to find it is the question that needs to be addressed. That's a simple example of course because there are only two likely locations for it (and the later is unlikely), the file/directory you're looking for has a name you remember off the top of your head, and because either of those directories probably has no more than a few hundred entries (probably a fraction of that.) In this case the user of a hierarchical system doesn't run into much trouble because the situation is virtually ideal, but even so a tagging system would have simplified the query. The further you get from ideal circumstances, the larger the gap between tag systems and hierarchical systems grows.
Additional thoughts on record oriented file systems: one example is Files-11 from VMS. An interesting property of Files-11 is that it allows files and directories to have multiple parent directories, which is similar to Unix's hard links except that directories, not only files, are allowed to have multiple parents. This gives the system the same expressive power of tags (consider each full path a file can be found at to be a tag on that file.) This allows all of your books to simultaneously be in /Books/ while still allowing you to have them in other locations like /School/cs/cs101/textbook.pdf However a system capable of expressing these relationships is the easy part. The important part is giving the human users a clean user experience, allowing them to take full advantage of the power of such a system without requiring them to manually create and maintain a web of nested links.
I'm looking at some folders right now. Physical manila folders, three of them in fact. I have one labeled "Bank Statements", another one "Health Care" and a third one "Car file". When I receive a bank statement, I stuff it into the back of the "Bank Statements" folder---I don't "name" the statement, it just exists with enough information on it (dates, "page 1 of 3", etc) to find what I'm looking for. Same for the other two, although for the car, it contains not only insurance receipts but maintenance receipts, tire receipts, etc., roughly in chronological order. The order of the folders themselves changes---whatever was last used is usually in/on top. And they're placed spatially---just to the right of my computer.
I do have other physical folders, just stored in three plastic bins in the closet. The bins are unlabeled, but I know what each one contains just by glancing at the contents and from there, knowing that my old computer science articles I want to keep folder is in the middle of this particular bin. Again, most of the folders are unlabeled/mislabeled but that doesn't matter to me because I know.
A filesystem can't quite replicate this spatial or looks feature of physical folders. There are also restrictions on what you can name a folder or file. For instance, I might want to name a file "Foo Inc. Invoice, Project: Snafu 3/19" but I can't---on Unix and Windows, the '/' is forbidden, on Classic Mac OS, the ':' is forbidden. Yes, I could place it in the "invoice" folder, or maybe the "projects" folder, or maybe the "foo" folder (or all three with hard/soft links) but now there's some cognitive overhead of just remembering where (unless I use links, but that's a weird thing with no real world counterpart, a physical folder can't exist in three different locations).
The spatial thing is important (but it could be just important for me). I've been using a virtual desktop on Linux for nearly 20 years now, in the same 3x3 configuration. The upper left corner is email; the middle right is the browser. Bottom left is a realtime view into system logs. The middle left and middle middle is where I do most of my development. The remaining spots are for overflow or temporary areas. When I got my Mac at work, I set it up with a similar spatial setup [1]. It helps to keep me oriented with what I'm doing.
And yes, I do know and understand the hierarchical file system, but that I still lose track of files from time to time ("I know I did this at one point---where did I put those files?"). I have 1.3 million files in nearly 200,000 folders in my home directory. It's amazing I can find anything at all [2][3].
[1] It's a linear series of 9 screens, but I still treat it as a 3x3 matrix of screens.
[2] A few weeks ago, I wanted to find the original image I used to make the favicon for my website about twenty years ago. I failed, and started a search with Google Image to see if I could find it (since I originally found it on the Internet). No go. A few days ago I found a folder I forgot about and lo', there was the original image.
[3] I also have 3,000 symlinks, three sockets, one named pipe, and 6 "others" (whatever those are).
In fact the system I've created as a testbed works by storing a many-to-many tag-filename mapping. However my contention is that hierarchy can be modeled as a subset of tags. Tags are conceptually more powerful and should be the interface exposed to users, not hierarchies.
That hierarchies can be expressed by tags is easy to demonstrate. Simply tag each file with all of it's parent directories up to root. Implementing hierarchies in terms of tags is not as computationally efficient, so you wouldn't actually write a filesystem in that way. The point is to create a new interface for humans, not for software. When a human has a dataset that is genuinely best organized as a hierarchy, they can express that hierarchy in terms of tags.
Of course traditional file hierarchies implemented in the traditional way, not in terms of tags, must still exist for some purposes. Source code, which requires a deterministic and efficient way to refer to specific other files, is one example. (However the user could still benefit greatly from augmenting the source code tree with tags.)
What I'm suggesting is not that hierarchical file systems be removed from operating systems, but rather that they be removed from nearly all user interaction with computers. The "Save as" dialog should not be exposing the hierarchical file system, at least not by default. Ditto the "Open" dialog. Hierarchical file managers like Finder, Explorer, Dolphin, Nautilus, etc should all be revised to be foremost file tagging systems designed to aid the user in managing and querying their tags. The "Desktop" should not be a directory on the filesystem, but rather a tag (or even a complex dynamic query.)
>Users think of their files as having concepts associated with them. e.g. "this file is a photo, about my vacation, and is about scuba" or "this file is a book, about scuba"
Why would someone think of files like that? I don't organize physical objects that way. My books are on my bookshelf and my pictures are in albums or frames. Why would a computer be different. I wouldn't store a book about scuba diving with or relate it to my vacation pictures of me scuba diving in any way in real life, why would I do this on a computer?
If I had a collection of books on my computer and pictures from my vacations it would be stored the same way I would do it in real life, keep the books together organized however and keep the pictures together organized however. The topics of my vacation pictures and my books have really nothing to do with eachother, even if they happen to be related.
What you describe sounds like the very opposite of how i'd want my files organized.
> "I wouldn't store a book about scuba diving with or relate it to my vacation pictures of me scuba diving in any way in real life"
You don't put every single physical item you have relating to scuba into one big bucket because in the physical world, putting something into one bucket precludes it from being placed into another bucket. When you are organizing things you have to anticipate your most likely queries in advanced. So maybe you have one shelf for science fiction, and another for marine wildlife, and another for all your programming language books. For a while, this works well enough. One book can't go on two shelves, but with few enough books that's not a deal breaker.
However, when your personal library grows large enough, this system rapidly becomes impractical. At this point, the librarian resorts to creating a card catalogue, categorizing books by author, subject, etc. Books which have numerous topics have numerous cards in the card catalogue.
Since this is the 21st century, card catalogues are now digitized. The digitization of card catalogues saves space, but more importantly it facilitates more powerful queries. You can grab two different stacks of cards, relating to two separate topics, and instantly find the intersection between them. That is, the list of books which appear in both stacks. This greatly reduces the number of cards you must look through to find a book that you're quite certain is in both of the stacks. For instance each stack might have a thousand cards, but the intersection of those two stacks might only be 50 cards. That's 50 cards you have to search through to find your book, instead of a thousand.
A file tagging system is a digital card catalogue for your files. And as librarian of your library, you can decide which subjects warrant their own tags and which don't. What you don't have to do is decide ahead of time what sort of queries you want to facilitate. And it's no longer important to keep your collection of books and photographs separated. If you want a book, you intersect whatever you're looking for with the card stack of all books. If you want a photograph, you intersect it with the card stack of all photographs. If you have a book of photographs, it could even be in both, should you want it to be.
It's not a matter of not having the physical space, it's a matter of my brain doesn't associate things that way. My computer isn't a library. It's a box full of my things. It's got my pictures, documents, music, movies, programming, music, art and miscellaneous projects, and various other things all stored where i need them to be. I don't need a relational database or tagging system for them. Everything's got a place based on its type or purpose for existing on my computer.
When i look for things on my computer, i don't have a vague concept of an idea of a thing i'm looking for, i look for specific things for specific purposes. Why would i need everything on my computer related to cats showing up if i'm looking for say, a cat sprite in a game i'm working on vs a picture of my cat or say a cat meme? I have no need for the other two things if i'm looking for one of those things. Yet in your system all those things and more would show up should i search for cat. That's pointless. I'd rather navigate to my programming projects and assets folder for my cat sprite, and go to my pictures folder for my own cat or meme cats. There's not many situations where i'd ever need all three at once.
For a library or massive database, sure, a file system may be insufficient. But as system for organizing things i need and use for specific purposes, it's not ideal.
> "When i look for things on my computer, i don't have a vague concept of an idea of a thing i'm looking for, i look for specific things for specific purposes."
What you're describing is that this sort of system excels at. By describing the properties of the specific file you're looking for, the tagging system can locate it very rapidly. Without a tagging system, knowing the file you're looking for is like knowing the bookshelf your book is on. If the book shelf is small, you can look at each book in sequence and find the one you're looking for. When your bookshelf is very long, it pays to reduce the set of files you're looking for.
>"Why would i need everything on my computer related to cats showing up if i'm looking for say, a cat sprite in a game i'm working on vs a picture of my cat or say a cat meme? I have no need for the other two things if i'm looking for one of those things."
If you have a single cat sprite, and search the intersection of 'cat' and 'sprite', then that single cat sprite would be returned to you.
Consider instead you have in mind a particular photograph of a cat and a dog, on a car. Perhaps you know you put that image in your cats directory, which has a thousand images because you're an avid fan of cats. To find that particular cat image, you'd need to search through a thousand images sequentially, unless you happen to remember the precise filename of that single image out of a thousand. Thumbnails will help, but that search is still going to take way longer than it should. If your collection of cat images is properly tagged, then you can instantly get a list of the intersection between cat, dog, and car. That list is going to be much shorter than 1000 images. It will take you seconds at most to glance through it and find the precise image you were looking for.
With terabyte harddrives being dirt cheap commodities, there is no real reason the average person couldn't or shouldn't have hundreds of thousands to millions of files at least. The reason most people don't is because with the organizational software currently available to them, (e.g. windows explorer) there is no feasible way for them to keep that many files organized. There is no good reason that should be the case.
Having dealt with many technologically inept users in many departments including HR and Finance, I can confidently say that file hierarchy was NOT a concept they were struggling with compared to others.
Fewer permissions needed for app private data, automatic clean-up of the files for an app, implied better security of said files because they're in a sandbox, controlled access to certain file data (location info in photos is only visible to the app that is the device default for photos), etc, etc.
Have they though? The filesystem of almost any user-facing system ends up full of detritus lacking clear ownership. Everyone just uses search now, because hierarchical structure requires a lot of effort to maintain and doesn't align that well with how most people think (should it be July/Invoices or Invoices/July?).
And that's not even getting into the security issues with a shared filesystem, where a single evil process can access all your data.
But if the user (read: a power user, like myself) really, REALLY wants to give a app that access, what now? I have no choice but to operate a root'ed device?
They're leaving no way out, and making things like "Syncthing" and general file managers really hard to continue operating.
> I have no choice but to operate a root'ed device?
That's becoming the answer with everything on Android, for anything useful you want to do, you need to root the phone. The stock phone is becoming just good for running Facebook and Candy-crush.
> A communication-only device that can take photos and browse the web is very useful, but I think it will lose market to a proper computer every time.
It might not. Every phone company has strong incentives to optimize their offering to the lowest common denominator. Majority of people are not tech-savvy, and they have no context for what computers are capable of and how those capabilities could be applied to their lives, so they simply choose from what's being offered by hardware and software companies. People who care about this stuff are a minority, and there's not much money in catering to them.
If computers could be bicycles for the mind, the modern trend is making people sit on their ass instead, and consume what's delivered to them.
Probably. What you are describing is essentially creating an app that runs as root, I guess. Literally the only thing changing is that your downloads and photo folders will now be Content Providers instead, I assume. You never had full access to the file system without OS level permissions.
> The filesystem of almost any user-facing system ends up full of detritus lacking clear ownership.
Because files don't always have a clear ownership. I have a folder full of photos and I don't want any particular application to "own" them. That a file corresponds to a concrete app that owns it is a lie, that's being pushed hard by mobile OSes.
1) They're too complicated for Joe Average User to understand and keep in order.
2) Companies make more money by having you store all your data in The Cloud: you have to pay (somehow) for storage on their servers, they get to comb through your data and mine it and use it to advertise to you, and the cellular companies get to charge you for access to your own data because you have to constantly transfer it wirelessly instead of keeping it local.
I'm not convinced. This seems like you are forgetting about every piece of malware ever. It seems hyperbolic to say that the filesystem is served "well for decades". Besides, it's not abandoned, it's just no longer shared storage. I don't see the problem. Apps have plenty of ways to share files without it, and sharing via filesystem is almost always the wrong way.
Are the other ways good? If I create a file in app A, choose 'send to' app B to tweak it, open this file and a bunch of others in a batch processing app C using the file selector, in the end where is my file? Where's the most recent version, and can I go back to it in app A? How many redundant obsolete copies are still on my device in different apps?
Not only that, suppose a system update disables app A. It only quits as soon as you open it and the developer has abandoned it. Fine, it's just a photo viewer, I'll get another one. Wait, where are my photos now?
When you pass around file URIs between apps (using Intents for example), the target app gets permission to process the URI (which can be a file or something else).
So no redundant obsolete copies. This mechanism has been in Android for years now.
Still, unless the system allows for a general file viewer, I may eventually lose the access to a file, simply because the application I used to initiate the chain of intents disappears from the store / stops working / whatever.
Of course the original app must also permit the receiving app permanent access to that file in the first place, plus the receiving app can only ask the OS for permanent access to a relatively limited number of files.
And for files that might be opened through multiple apps (say you downloaded a picture - now you could reasonably launch a photo editor for that file directly through your browser, or through a file explorer, or your gallery or ...), each sending app will generate its own URI and the receiving app has no guaranteed way to decide whether those URIs all refer to the same app or not.
Physical windows don't serve us well when you consider every burglary ever. We should just not put windows in buildings, everyone can rely on their HVAC provider which promises 5 9s uptime to keep from suffocating. Besides, its not like we are just sealing the buildings completely, just limiting access to HVAC staff.
Main reason is for you to only use cloud storage and services. Google doesn't make money if you own your music and play it at will from an sd card. Google makes money if you have to shell out $10 a month to play the same music again. Replace <music> with anything else -- works the same.
Big tech wants you to not own anything, because in that case you'll have to subscribe to everything. If you can't subscribe or you don't have enough money to subscribe they'll make it "free with ads". But one thing is a no-no -- you buying and owning any content.
So summed up- there will soon be a app called file-system, which provides the expected behaviour through the Object-Orientated Cruft to every app needing it?
That's the intents system. You just declare that you want a file. A picker then opens up with every app that has files available, the user selects one, and you get a handle to it.
* Apps are only allowed to access only files that the user explicitly allows them access to. (No more Epic games launcher slurping up your Steam library information)
* Apps can present file-like objects to the file picker and have them work transparently. (No more one-off filesystems to just forward an API call)
* Apps don't have to know anything about permissions. You just get a blob of data.
While I get the thinking behind content://-URI and accept that their beneficial for some use cases, as currently implemented they still break a lot of things, too:
> * Apps are only allowed to access only files that the user explicitly allows them access to. (No more Epic games launcher slurping up your Steam library information)
This assumes that all content you possibly want to open in a different app always consists of a single atomic file.
Unfortunately that's not always the case, though. If you open a HTML file from your storage, you'll likely want your browser to be able to access the accompanying images, style sheets, other locally linked files, etc., too, but under Google's file access model that's not possible. Or say you open a video file where you've also thrown some subtitles into the same directory - unfortunately your video player will only be able to open the video itself and never even learns about the subtitles.
For a small demonstration, just copy some archived web pages to your storage and then try using the built-in file explorer (which uses the officially sanctioned way of content://-URIs for launching apps) to view one of those HTML files in either Android's mini HTML viewer app or else Chrome and marvel at the missing images, broken styles, non-working links...
> * Apps can present file-like objects to the file picker and have them work transparently. (No more one-off filesystems to just forward an API call)
> * Apps don't have to know anything about permissions. You just get a blob of data.
Unfortunately it also completely hides the underlying file system, so even if the file in question is one that a) is actually sitting on the local storage and b) is stored somewhere where the receiving app would have access permissions itself anyway (because you've explicitly allowed that app to access that part of the storage), you still have no official way to get a reference to the original file.
This is a problem because if the receiving app could open the file (and accordingly also its companion files) using its own permissions, it could in fact avoid the issues resulting from the first point. As it is, you're somewhat stuck, though.
Depends if it's in the app storage or the user storage. I'm afraid they'll neuter the user storage, which would be the final nail in the coffin for me.
Probably. And it's bad, because our devices are so powerful and we aren't leveraging them. I wonder someone else will come to the rescue soon and move mobile forward usefully. Its pretty stagnant now, neither Apple nor Google innovate. Its Samsung and Xioami mostly now. Would be funny if someone like Microsoft would deliver something novel soon to see positive changes for consumers.
I think most people like Windows Phone. I certainly did - it was the best phone OS by far imo. Writing this from my iPhone only because the Nokia died. The real problem was the app story, and part of that was due to the influence of Google.
A lot of great products beloved by a lot of people fail in the market despite their quality for all kinds of reasons.
In this case, the lateness of the product, the continual burning of their phone platforms, anticompetitive behavior of Google and some of its associated companies, carrier disinterest, and a lackluster marketing campaign are among the reasons it failed.
I doubt you will find many people who tried or used the phone who didn’t like it.
No, it wasn't. I have one with WP10. They at some point killed external storage as well and I couldn't fit 120GB of HERE maps data to my main storage, which killed the only reason I was still using it.
<10% users liked WP/Windows 8 design. There were some stats about it. Don't you remember how much people complained when Win8 was released? You could consider yourself "elite" or an "outlier" if you liked WP/W8.
Windows Phone 8/8.1 and Windows 8/8.1 are different things and on different platforms. The stats apply to the desktop OS, not the phone OS. Even if you wanted to pretend they were the same, the most frequent complaint was I don't want a phone OS on my desktop.
You can still see this in most reviews, too - reviews of Windows 8/8.1 are generally pretty negative, while reviews of WP 8/8.1 on the same site are positive to glowing.
Windows Mobile 10/Windows 10 are the only ones that are nominally the same and still are in fact very different.
Again, if you talked to people that actually picked up and tried (or bought) a Windows Phone, they were almost universally very pleased with the phone UI and OS. The single biggest complaint you will see is about the app selection.
That's not true. I even remember talking to some Nokia guys that expressed how everyone hated WP7 design and how much rather they would have gone with Meego or Android. There were polls at that time where like 7% of people liked WP design. Just because MS spent some money on marketing to get nice reviews doesn't tell much, but if you want to stay in that echo chamber, it's your choice.
And please don't be condescendingly academic about WP/W8 distinction. The "ugliness" of UI people here talk about is present on both platforms and you still have to do some work to hide it on W10 (e.g. manually unpinning tiles from start menu after each upgrade, confusing system settings, disjoint set of options in old vs new UI etc.).
I don't know anything about WP7, except that it was completely different from WP8. Searching for screenshots shows some basic design similarity, but it ultimately looks nothing like the OS I used. It is one of the reasons that the WP platform was floundering, since WP7 apps did not work on WP8. Either way, remembering a poll can be a tricky thing.
> And please don't be condescendingly academic about WP/W8 distinction. The "ugliness" of UI people here talk about is present on both platforms
I googled "Windows Phone 8 review". This is typical of the results I get.
Windows Phone 8 makes significant changes while remaining true to its core. It's sharp, colorful, clean, and simple, but also hip and a bit exuberant. New features include a surge of NFC actions, greater customization, and a heavy peppering of more-minor additions and adjustments; yet it's the tile-based interface that continues to be the operating system's most distinctive and defining characteristic.
The UI is virtually always called out as great and great looking, even if the reviewer ends up not liking the rest of the package.
I actually liked WP8 once I was allowed to make tiles transparent, and they just partitioned whichever wallpaper I chose with "launcher rectangles". It was a quite cool design actually. But the original tile layout with that disgusting color palette one couldn't change was obviously something that should have been confined to some modern art gallery for the people that could appreciate it, and never tried in mainstream.
I felt like the tiles displayed the right level of information where I could quickly glance at my phone and see if there was anything important that needed my attention, while helping to reduce the mindless time I spent getting distracted by noise.
When I was using my Windows Phone it felt like the UI was built to decrease interaction with the device, which was a positive to me. It was trying to get the right information in front of me so I could get back to being detached from the screen.
I tried one once, and I'll admit it wasn't a bad idea and seemed to work well, but, like with everything Microsoft makes, it was just plain ugly. HN users are completely discounting the importance of aesthetics here, as is typical for technical people. Just look at pre-MacOSX Apple: they always concentrated on aesthetics and made very pretty computers and UIs, even if the OS on a technical level was total garbage (no pre-emptive multitasking!), and that kept them alive long enough to become the behemoth they are now, where technically they're still not that great, but aesthetically they do well and have legions of loyal fans.
The other thing that killed them, as many have noted, was the lack of apps. That's because they were too late mainly; they were a me-too after iPhone and Android had already established their dominance. What app developer wants to spend a lot of time and resources developing a 3rd version of their app for a new platform that no one is using yet?
I didn't think Windows Phone was ugly at all but that's unimportant; I feel pretty confident that aesthetics didn't contribute much to the platform's failure.
It did alright in Europe but overall, the Windows Phone campaign was inexcusably mismanaged to such a degree that it seemed deliberate. It felt abandoned almost from day one. It was unlikely you'd see one anywhere, in any store, because it'd been relegated to retail backwaters like the Microsoft Store.
It was frustrating to watch. Essentially the whole Zune thing on replay. Microsoft does not do a good job of presenting a united force to get a product in front of the eyes of consumers or generating any sort of hype.
And then they ran Nokia through a corporate shredder, just in case you were worried that Windows Phone might have a future.
>the Windows Phone campaign was inexcusably mismanaged to such a degree that it seemed deliberate
From what I remember in the US, the phone stores just weren't interested in pushing them too much, for various reasons. That's not MS's fault.
Maybe you didn't think they were ugly, but a lot of people did. Aesthetics have never been MS's strong suit, nor has naming (their names are always horribly boring and unimaginative, unless they buy it, e.g. PowerPoint or Excel).
MS also had a bad reputation because everyone knew they made the OS on their home and/or work computer that crashed all the time. XP will still in use at that time, remember, and 95/98/Me weren't that far in the past at that point.
MS also has a bad history of abandoning their products. You mentioned Zune; right before that, they had "PlaysForSure", which didn't "play for sure" because they abandoned it and all those customers were screwed. On Windows Phone, people who bought the earlier versions were screwed because they were incompatible with the later versions. (IIRC, this was a big problem because the apps were incompatible between the versions, and this made the app store problem even worse.)
> The other thing that killed them, as many have noted, was the lack of apps. ... What app developer wants to spend a lot of time and resources developing a 3rd version of their app for a new platform that no one is using yet?
Sure, there was a lack of apps; but it wasn't all because it was too late; Windows phone 7 wasn't _that_ late to the game, and there's value being the only app for X on a platform, even if it's the smallest platform. The problem was your windows 7 app didn't work right on 8, and you probably should rewrite it again for 8.1, and you definitely need to rewrite it for 'Universal' Windows Platform for 10, except that's a waste of time since 10 never got anywhere close to the number of users as 8.
If Microsoft hadn't effectively killed Windows Mobile 10 by merging the desktop and mobile teams during development, and ended up with a solid Windows Mobile 10 release at launch, they would have been able to continue as a third platform. Supporting WP 8 devices upgrading to 10 and continuing to release lower end devices on 10 would have helped get existing developers to update their apps for 10. Having a decent browser would have helped, but Microsoft was playing the 'pretend to be iOS' game too hard, and blocked browsers from the store until it was too late; Firefox wanted to release for WP, but Microsoft said no, and IE/Edge are IE/Edge.
Given all of the things Google is doing to try to rein in apps, like Doze and this storage api revocation; it would be nice to have an option that isn't iOS.
WP 8 may have been ugly, but it was functional, and had a dark mode _everywhere_. The better tiles were really useful for getting the right amount of information, and because they were a critical part of the UI design, most apps supported them, unlike launcher widgets which are pretty hit or miss. Number badges require you to go in and reset the count to zero or they don't provide a useful signal; seeing the last message lets you delay it to later.
Funny, maybe I'm a stereotypical HN user here, but I liked Metro UI. I liked it more than Material design nonsense and skeuomorphic Apple crap. Windows Phones' UI was simple, to the point, and evoked the feelings of being half-way to Star Trek interfaces. Maybe it resonated with me because of that.
Apps were part of what killed Windows Phone, but I also think they released their OS with too little built-in features. My brother used to own a phone with early Windows version; it lacked a lot of small conveniences and tweakables that were available on contemporary Android phones. I vaguely recall sharing media with other devices was a problem; not unlike how it's with iPhones.
Actually, the UI was the best from all vendors. It was, after couple iterations, extremly slick and useful at the same time! The OS was the best probably too, but the ecosystem with apps sucked. The good thing, MS still has all that in the pocket to pull something off down the road- certainly, they must be working on something in that area.
Metro UI started to look good once they allowed fully transparent tiles without those horrible predefined solid-color boxes, i.e. you could select a background image and it was then tiled to launchers:
If they had that from the day one, it could have ended up with a lot less resistance (just the ugliness of the default palette was unbearable; they must have hired an expert for achieving the most negative impression with those original tiles/colors).
Google doesn't innovate? The software on the new Pixel 3 is nothing short of amazing from spam call answering to night mode photography. And it is all getting backported to earlier Pixel models as well.
The vast majority of people are leveraging them, to do the things they want to do, such as taking photos, video calling, navigation, checking email, visiting websites, listening and watching media.
What the vast majority of people also don't want to do is spend time and effort dealing with malware. Hence the success of locked down systems.
True, but that experience can be offered with a fraction of the prize for consumers - maybe that's where breakthroughs could happen. Cheap "feature" phones for the masses again.
> The vast majority of people are leveraging them, to do the things they want to do, such as taking photos, video calling, navigation, checking email, visiting websites, listening and watching media.
In frustration and at 25% or less of the actual capability, because of stupid design choices that destroy interoperability. This is mostly a consequence of an app market of selfish independent actors, but at least the operating system could encourage more interop, instead of trying to destroy it.
The problem is that everyone who attempts this tries to start from scratch and then has the network effects problem, when what we really need is for someone to play GNU/Linux to Android's proprietary Unix.
Make something that will run the same apps, on the same hardware, but put the user in control of the thing. Then add all the interesting features you wanted to put in your independent system.
Which is easier in this case because it's possible to fork Android and start from there. The major problem seems to be the driver issue on mobile. The drivers are blobs tied to a specific kernel, which makes it hard for people to try out the new thing on their existing phone, which suppresses adoption and participation. And that's also the thing that prevents you from even upgrading your old phone to a newer version of vanilla Android.
So it seems like what we badly need is a solution for that.
Google was smart and sort of protected itself from Android forks years ago, when they started putting more and more functionality in Google Play Services. Most apps need that to run now, and it isn't open source.
I've always hated that apps were allowed to do whatever the hell they wanted on Android. I'm happy to see these changes, as Android is cheaper than iOS, and now I've got two options instead of one.
This seems like it's only an issue if you install apps you don't trust. It seems to me that the premise that you would want to install apps you don't trust is itself broken. Why should we give up the power and utility of our devices just to make this safe?
If it even can be made safe at all. I would have thought that Meltdown/Spectre would have made it very apparent by now that trying to perfectly isolate two programs on the same machine is like trying to make a colander float.
Well, its a matter of degrees. I might want an app that I trust to have access to photos, but not my whole SD Card. That hasn't really been possible in the past.
And we've seen that apps that are trustworthy can be bought and sold, sometimes by companies that are very untrustworthy.
While trying to achieve that control, does this change really allow your most trusted apps to keep the same level of utility? It doesn't sound like it, for example it sounds like Termux will no longer be as useful
I don’t know how to trust an app. Like, how would I make that decision?
When I used Android, I just didn’t install things unless I really, really wanted them, and they were popular enough that I figured security researchers would likely be looking at them closely. (Which, of course, was a great incentive to keep using Google’s ecosystem for everything.)
I tried iOS a few years ago, and one of the big differences is that I’m a lot more confident about trying random apps; I know there’ll still be shady apps, but Apple’s vetting and the iOS security model give me a lot more confidence. I’ve installed (and paid for) a lot more apps as a result; my phone’s much more usable to me.
Like, how do you decide which apps to trust on your PC? While Windows does have a store, I'd wager the majority of installs are still done by downloading .exe files off the software's homepages. Executable binaries that run with full privileges, with minimal permission granularity, no less.
Somehow we're not discussing prohibiting filesystem access for personal computers? Why is this an issue for smartphones, a.k.a. a pocket-sized personal computer?
I wouldn't say that. SD Cards and local file selection are still possible under this model, and it is still possible to share files between apps like this.
It is just that now there is a lot more control to insure that the user is aware of it, and some new technical limitations.
Android is becoming more and more useless every year, we could have a powerful computer in our pocket to do everything we want and instead we have a dumb device with a clunky system which is just good for running chat apps and small games.
I want the Nintendo Switch of phones. I want to seamlessly walk off with it or put it into a dock and Bam, full desktop OS. But a good one. Not the janky answers that usually get posted in reply.
Samsung's DeX experience is pretty much there. At this point it's apps failing to account for user experience in desktop mode that 's holding it back from a usability perspective. Hopefully that'll change when Q Desk Mode is widely available.
That's exactly what I want as well, phones are powerful enough to do that. I could even use the phone screen as a second screen terminal and type with my keyboard in both, switching with ctrl+something.
Everything is technically complicated on Android, I've also worked into customizing ROMs, trust me, Android kernel & top layer are so clunky that it's even a miracle that the phone is switching on. There's really nothing we can save from this garbage system. Sorry for the Android fans reading this but that's truly my personal opinion after digging into it for a few months. it's just piles and piles of hacks as far as the eye can see.
Seriously, give me a phone running windows 10. Not windows 10 ME or some other special edition, just regular windows 10. They went to all the trouble to make the OS touch-friendly then failed to put it on a phone?
Microsoft did have Windows phone. Metro was an attempt to converge desktop, phone, and tablet environments. From what I hear, Windows phone was an excellent product, but it was late to market and did not have a healthy app ecosystem.
This would still be the case if you put Windows 10 desktop on a phone. The problem is that even though the Windows desktop has a healthy app ecosystem, these apps work poorly on touch devices. This is true for touch devices with large, high-quality screens (various desktops) and for smaller, more portable, but still high-quality screens (like the Surface). Rewriting an app to work well with touch turns out to be an enormous amount of work for the typical Windows app developer. This is true in the ideal case, for C# devs working with WPF/XAML, but it is much worse for devs working with older apps... WinForms, MVC, etc.
Without the desktop apps, you're left with something that is basically an also-ran in a market saturated by iOS and Android. In the meantime, the desktop experience is still not completely touch-friendly and has suffered from a fair amount of design damage in the process (e.g. two control panels). Any developer that would go through the process of getting their existing Windows app working with a touch UI is going to evaluate porting to iOS or Android, and probably prioritize those options.
Seems like a good startup idea, honestly. Might really work well if Android or iOs apps run well too.
[Edit]: I should also add that I really want the opposite of what you ask for. I really want my Android apps to also be available on my desktop PC. It would be really cool if I could plug my phone into a clamshell laptop-like device and have a big-screen experience.
On the upside, this is still being worked on. The UBports community is still active, and KDE has been refining its plasma mobile interface. Purism's librem 5 should be convergence-capable.
Window toolkits are also being developed to help create responsive applications: Kirigami and libhandy, to name a few.
On the non-opensource front, there is also Microsoft's UWP, and samsung's DeX is showing some promise.
We're getting there, but slower than anticipated. The EOMA68 is also a promising concept, though slightly different, and more similar to what the parent describes.
Way back when the iPhone came out, I dreamed that it would turn in to an extension of one of Jobs' ideas for NeXT (in the original form, optical drives) - your home directory lives in your pocket, and plugs in to whatever machine you're in front of.
Never happened, and instead we got 19 flavors of "cloud sync", which doesn't solve the problem and has nasty security implications.
I traveled for a year with not just my ~home, but my entire OS, settings,and applications all on a portable USB flash drive.[1] The data was backed up in the cloud and the drive encrypted. If I justed need to review a file, I had cloud access and viewers on my phone. When I needed to do any real work, all I had to do was plug my flash drive into any PC with a USB port.
A high quality flash drive[2] boots up instantly and loads apps instantly. I can't work on a 3" screen and don't want to carry around anything any bigger. So for me this is a better solution than a docking station for my phone.
What year was this? BIOS settings on PCs sold the last few years complicate booting from USB. Were you fiddling with BIOS settings on strangers' machines?
Also, in the case of public computers, the risk of keyloggers means you cannot trust the computer even if you boot your own OS.
Actually done this twice, once in '10 and again in '16. BIOS issues only came up a few times in some chain cybercafes that were locked down. Never had any problem with the mom in pop cafes that were managed by hand. The rest of the time it was an office, friends/family, hotel, or my own laptop. In those cases, I didn't have to modify any BIOS, it was enough to boot with and pressing Esc, F1, or F12 to brings up the boot menu.
> risk of keyloggers means even if you boot your own OS.
While it's likely the OS of some of the machines I used were infected, the odds of them carrying firmware based backdoors was not a concern. The odds of getting dengue fever were far more likely than a hardware level hack. Those attacks are very hardware specific limiting the potential for widespread infection. At the time Snowden was still fresh on my mind. So I was more concerned with the NSA was sucking down all my emails / cloud data. There is only so much you can do.
Had I been using the OS on the cybercafes, I'm sure my risk of getting keylogged would have been 1000x more than using my own OS on their hardware.
When I plug in my USB key, I have to inspect in the back ports of the compute, where I easily can spot a hardware keylogger. I've never seen such a device in the wild. Sure it’s possible a cybercafé somewhere in the world has one... but how big a threat is this really? I'd say my risk of Dengue Fever was 10000x more likely than this. Never mind how easily it would be to detect.
How many of their users bring their own OS on a flash drive? In my travels, I only met only 1 other. One. He was running Tails. And as I said the chains with their management software and BIOS lockdown don't even allow this. So we're talking mom and pop cafes.
Now do you think those small time owners are going to spend their money to add this additional cost to spy on that one traveler who has his own OS? That make zero sense when they already control the OS and network. So much easier to spy on customers on that level. In that case, VPN + my own OS circumvents them.
Your paranoia only makes sense if I was going to DEF CON or some kind of a target of state level spying.
I predict the iPhone to be something like that - the rumors on MacBooks on ARM are loud. Having the phone dock into a screen/keyboard/mouse workplace and displaying a mouse-friendly desktop isn't far of.
> Having the phone dock into a screen/keyboard/mouse workplace and displaying a mouse-friendly desktop isn't far of.
How do you imagine this would work even in theory? Running two OSes side-by-side (one when in phone mode, one when in desktop mode?).
Or running two largely incompatible desktop shells with largely incompatible interfaces for multiple apps (touch-optimised programs are very different from mouse-and-keyboard-optimised programs)?
For applications there is lots of work to make it really nice. Putting mobile apps on "desktop" can be done, while user interface will be a bit strange. But that's a thing which needs time. Microsoft tried that by pushing mobile on desktop, but they didn't have the mobile story. Apple has notable Userbase on both.
There were some such devices, running Windows, in the mid-2000s. Larry Augustin (Sugar CRM, VA Research) was associated with one start-up during his time at Azure Ventures.
Why does the "powerful" computer need to be in your pocket. I have a Shadow Tech machine, and with their IOS app I can access a really nice computer from my phone.
As long as I have a bluetooth mouse and keyboard, I'm having the full desktop experience from an iphone that's 3 years old. I can even cast my phone to a wall sized projector which is really fun. Only caveat is that it requires a very good internet connection.
Because the ultimate fully private and fully secured mobile device is an acid-covered rock. These "privacy features" destroy interoperability and take away user's control, rendering the device even dumber and even less useful than it was before. It could have been done better, in a way that provided security while preserving utility, but - as is the trend - it wasn't.
Each time your app opens and reads a file, the application on other side of ContentProvider can monitor user activity down to number of bytes read. Each time you open a directory, that action can be noted. If anything, that sounds like a privacy nightmare, and will undoubtedly be exploited.
So does this mean the end of apps like ES File Explorer?[1] I use that app all the time to manage downloaded files and to transfer local files to my NAS / S3 buckets it'd be a very sad day when that sort of functionality becomes impossible.
Regarding ES File Explorer: I used it heavily years ago, but with every new version I felt it became scrummier and sleazier and was not comfortable to continue, even with its impressive features.
I also used ES before it was sold, and I've heard nothing but bad things about it since. I find Solid Explorer to be a much better option now. Mixplorer is good too, and free. Cx File Explorer looks good too, but I haven't tried it.
Yeah, I had almost stopped using the free version because of the user-hostile UX they kept pushing but they had a sale a few years ago and I picked it up then.
It's like a completely different app, all the cruft like ads and pushing other apps is completely gone. You're just left with all the good stuff and those features generally all work well.
I like its column-based view of the filesystem, and the wifi server that you can open a web browser to and upload files from your laptop/desktop.
Some of the features are paid, but frankly $5 for an app really doesn't bother me much as I try to donate at least that to the different open source projects I use a lot.
I'm sure there are a lot of useful technical features, but I can't get past that UI. That has to be one of the ugliest app layouts I've ever seen [1]. There's just so many unnecessary elements.
For sure, it can definitely be described as "quirky". My initial reaction was much the same as yours.
That said, once I tried copying/moving files around, I was sold on the 2-column layout. I recently got a new phone, which meant moving my custom ringtones and notification sounds to their correct locations. With Google Drive I downloaded them, then using X-Plore I moved them to the ~/Notifications and ~/Ringtones folders. That was fairly easy to do - you find the destination in the right hand column, then swipe back to the left column, select the files for moving, then choose copy/move.
It's kind of like the column mode in Finder on OS X, which I really wish I had on Windows 10.
To everyone looking for a decent file manager for Android, please check out MiXplorer[0]. I just discovered it and was immediately impressed with it's features and functionality. Some of my favorite native features:
* Very pleasing, nice-looking, easy to use interface (I know this is silly, but as much as I like Total Commander which is good I always felt it's interface was a little clunky.)
* Developer is very active and receptive to feedback.
Give it a try, it's free on XDA with a paid version on the Play Store[1] with at the time of writing, only 5 and 4 star reviews.
I went through all the file explorer type things, and while none of them are as good as Old ES File Explorer, I've found that the ASUS ZenUI File Manager is by far the best (I know, surprising that ZenUI bundled app wins, right?)
I think I could build it from source but I don't have an Android dev environment anymore so I installed the app from Google Play. It asks surprisingly few permissions: read/modify/delete content on the SD card and access to fingerprint hardware.
I bought the paid version before it was bought out. When I installed the free version on a friend's phone at a later date, it was unrecognizable. The paid version still looks like the old version, and works well.
Not necessarily. File explorers (and other apps) can still ask the user for access to specific files and folders (including the storage "root "), via the Storage Access Framework (SAF), which gives the app a sort-of-like-a-file-but-not-quite handle on the files and folders within the given tree.
That handle is probably good-enough for basic file management operations, like copying, moving or renaming files, but (from what I've read) if you want to, say, jump to the middle of a file, such as to read a specific file contained in the archive or seek to a specific position in a music/video file, it becomes very inefficient. If you want to read/write from a database (and need that database to be easily shared between different apps), then you also have a problem. If you use an app like Termux, which exposes the file system to standard unix utilities, and want to directly manage all your files with them, you're pretty much out of options.
Why doesn't the file proxy class have a seek or read-with-offset RPC operation instead of just handing you a stream of bytes? This isn't particularly novel for remote-ish file storage (SCSI supports this, NFS supports this, etc.)
Re Termux, I actively don't want any app on my phone to have direct access to the rest of the files on my phone. The fact that desktop terminal apps (cmd.exe, Terminal.app, xterm, etc.) require this access is the root cause of a bunch of security difficulties in desktop OSes that are impossible to solve in a satisfying way. I want a little workspace (potentially multiple workspaces) for stuff where a terminal is the right way to work, but I don't want the ability for any app to cd into my Signal storage directory or my email client config directory and edit files there.
As a result, I use iOS. If Android will get me the same security design plus the ability to call fork() so Termux works, I'd consider switching - it sounds like that's what they're doing.
> I want a little workspace (potentially multiple workspaces) for stuff where a terminal is the right way to work,
If you don't give Termux the "storage" permission, then this is exactly how it works now.
> Signal storage directory
Signal stores its data in its private app directory, which is not exposed to either any other apps, even if you give them the "storage" permission, or to the user via MTP. The only exception is the optional back-up, which is stored (encrypted!) in the public app directory (accessible to MTP and apps having the "storage" permission), so that you can copy it to your next phone. (AFAIK Signal on iOS doesn't give you this option...).
> email client config directory
K-9 mail also stores its data in its private app directory.
OTOH files that are not super-private, like books, audiobooks, music, maps or flashcards can be stored where they're easily accessible, manageable and processable by multiple applications (but even then, only applications that I grant the requisite permission).
I don't like other apps with vulnerabilities editing my email client config. If I want an app to edit my email client config, I'm happy to click something in my email client to explicitly authorize a specific vim in a specific terminal to do that.
If I wanted to use iOS I'd buy a damned iPhone. I spend a large fraction of my time in a file manager, moving files back and forth from network storage and to flash drives. How the hell am I supposed to to tell when an app is shitting the bed by, for example, keeping a 20GB folder of thumbnail images?
Maybe I'm missing something but this sounds like a disaster. Is this the end of locally stored music libraries? Epub readers? Anything that relies on access to shared storage? If so I'm done with Android.
It's ridiculous that a supposedly sandboxed text editor would have access to all your photos, for instance.
Apps should only have access to their own private storage and to data that the user has explicitly picked from a file picker or similar UI, which is what this update does AFAICT.
It seems a serious mistake though to not affect apps installed on upgrade and to disallow access instead of just providing a virtual private copy of the external storage for each app (though the latter is not clear from the article).
I use syncthing to sync files from several folders of my phone (internal app storage) to folders on my laptop (usually as a backup) and viceversa (usually because it's easier to download some files on my laptop, think about GPX tracks). This means that I need synchthing to access all those folders.
I also use an open source file manager app to access files on both internal and external storage. I need it to access all of it.
I understand I'm not the typical Google user as I'm logged in only in Google Play and Google Drive, which I use for work and not for backing up stuff. However if they turn Android into iOS maybe I could finally buy an iPhone SE when the last small factor Android phone dies. Not really, because that would leave me with a much more closed down environment. Alternatives? Maybe a Linux phone if there will be something around, but I'll have to keep using an Android anyway, so going around with two phones, which is worse.
What Google should do is give an option to lift all walls between applications (or root the phone). Void warranty and the likes, it's fine for me. I'm replacing all closed source apps from untrusted parties with open source ones anyway.
> This means that I need synchthing to access all those folders.
FWIW Google Photos does exactly this. It even scans your directories and pops up a prompt "Hey, I found a new folder with images, want me to back it up?". I really wonder how this will turn out...
Is there such thing as robot.txt for folders that could be implemented by programs/apps? There are plenty of things that create folders of thumbnails, ui/ux sprites, etc.
I'm pretty sure they don't hold themselves to their own app store policies (and neither Apple to theirs) and I remember there being a flagrant example but I can't find a reference quickly googling it.
Then make permissions more finely grained and don't give access to your photo folder. I for one want my text editor to have access to everything on the device. Same goes for file explorer.
It's ridiculous that we accept that every piece of software we install is malware. A flashlight sells our location data? A text editor scrapes our photos? It doesn't have to be this way.
That's what you get when you live in a world where most people aren't willing to shell out $1.99 for their apps. Developer time isn't free, and these apps are going to be monetized somehow.
On desktop, we have enormously complex software that's available for free. Why clang does not send all my passwords to shady servers and Blender does not lock my computer and demand ransom? Yet flashlight app which cost 1 man-hour to develop demands "$1.99 or all your private data".
I bought Office Suite Pro for 14$ or something on a rooted Android phone. Having access to the private data folder of the app (/data/data/...), I could read the content of a sqlite database created by the app... in which there was reference of all the files from the userspace storage (/sdcard).
According to their privacy policy, they collect all the "data needed in order to improve their services and offering" and "can provide these data to third-party" for that purpose.
Paying for an app on android platform is no assurance the app actually respect your privacy.
In my understanding that is/should be the main difference between internal/external storage. Internal/scoped/private: An app can only read from/write to its own area. External/shared: Everyone can read/write everything.
So does this mean that file-manager apps will no longer be usable? Because that's a serious DO NOT WANT. I need access to my filesystem on my device.
Doing stuff like this is a promise that their less-power-user-y tools will do everything seamlessly, a promise they have repeatedly failed to deliver on. Getting Google Music to play nice with a my SD card was a nightmare until I gave up and just copied files over the network onto it directly and told it "search this folder".
File manager apps (those which cared) can still receive access via SAF API.
They actually had to do that to expose all possible storages on Android - including OTG mounted drives. Apps that didn't do that will be broken now, but they weren't doing the right thing either way.
Why would anyone care which app created photos in a photo folder? I mean ask the user a permission for read/write access there, sure but once the photo is saved or should no longer which app created it.
Same goes for other for types. Sometimes I want an to be able to access all files on my phone as well. The whole thing sounds like huge step backwards and frankly just bad design.
I wonder what would happen with the apps like KDE Connect? I use the app to download photos, backup my phone, and generally avoid connecting to google shenanigans.
This is outright bullshit, one of the most useful features of Android vs iOS is that you have a proper filesystem that all applications you trust have access to.
I hope this isn't forced on everything and there is a flag somewhere in the settings that i can use to indicate which applications i trust that can have access to everything like before.
It's a super-useful feature for a very small subset of users.
Google has to balance making a phone that's useful to everybody and most of the people that buy an Android handset are more likely to be harmed by allowing apps access to the entire filesystem.
Except we can't in most cases; It's disallowed by vendors. The reason used to justify these arbitrary lockouts? Most users are "more likely to be harmed by allowing" it... Tautology much?
And you can still grant that access explicitly - or grant access to a subtree.
The only difference now is that apps won't get full, uncontrolled access to all your personal photos, documents and app data without your explicit consent and ability to limit them.
The major problem isn't that you now have to ask the user for access for a specific folder, but that you're also stuck with the Storage Access Framework's APIs afterwards, which are somewhat less than satisfactory to use (see also https://news.ycombinator.com/item?id=19525092), don't play nice with native code, etc.
It would be a different thing if the user picking a folder would also offer a way of giving you regular file system access for that part of the storage.
Would this affect access to Android storage through the USB interface, e.g. through the Android File Transfer app ( https://www.android.com/filetransfer/ ) at all? It is very convenient to just copy files from a laptop/desktop computer into the appropriate directories on Android, and then access them using apps.
264 comments
[ 3.0 ms ] story [ 250 ms ] threadSo is there now no user access to the device's file system?
At all, I mean.
And what about SD cards? And use of Dropbox or whatever? Or AWS and Google storage?
An app can ask you, as user, to pick a file for reading/writing/creation, and it receives access to something very much like a file, but the app isn't even permitted to know whether that's a file on the local device or an on-demand download/upload by another app.
So is this to help protect apps from each other? And/or to protect users from malicious apps?
And what if you've rooted the device, and installed your own file-management app. Could that app manage files normally?
One angle is it prevents apps from scanning your local storage for files and stealing them.
Another angle is that it blurs the line between cloud and local so that storing data on cloud services gets treated the same as local data. If you happen to own said cloud storage services (cough Google cough) then that direction aligns with your corporate interests.
I think you can manage files even without rooting. I plugged a phone (XZ1C, Android 9) into USB now, the computer offered to open the phone's storage, 2-3 clicks later and I see the photos that are stored on the phone.
No, you can't see your file system. Not yours.
Edit: There's a load of suggestions downthread, I think I might be on an older version of ES, maybe pihole is blocking some of the ads others are complaining of.
[1] https://github.com/TeamAmaze/AmazeFileManager
Regardless of whether you think it's good or bad design, at least it's consistent IMO.
But without an app to access it, how will the user get to the files?
... and which is also completely unsuitable for content that implicitly depends on multiple files, e.g. locally stored HTML files: For the case where an app is launched because you wanted to view a particular file, you'll only get access to that "something very much like a file" for that exact file only, but you (respectively your browser) cannot access any other associated files that might be required (images, style sheets, scripts and whatnot) that way, and neither would navigation among separate files stored locally work.
However, there is a setting to use SDCards as a partition extension and it appears as extra 'internal' storage space.
You could never access other app's internal files with this api. IMO this is a good change. This pattern only made sense when smart phones were simply nice camera phones with email.
Every normal user can understand hierarchy -- shoeboxes in closets in rooms in houses in neighborhoods in cities. The human mind orders things in hierarchies effortlessly. It's just incorrect to claim otherwise.
The only thing users sometimes can't understand are badly designed user interfaces for exposing and navigating a hierarchy.
Regular users don't have context for technology, they scoop up whatever companies offer on the market. If everyone gravitates towards the same crappy solutions, most users won't complain, because they can't or don't want to imagine how things could be made better.
And for desktop and phone purposes, search is popular because it works damn well.
It works well, until it doesn't. It's especially bad if you don't remember exactly what you're looking for; this is when a decent hierarchy is really useful. And yes, hierarchies have problems, which is why RDBMSs took over from the older hierarchical DBs which were used before that (such as on the Apollo program), but just throwing everything into a single directory and hoping file metadata and search will replace it all is wishful thinking.
In particular, search tend to be buggy, and if you have no reference hierarchy that you know shows you unfiltered results, you have no basis to trust that the results of your search query are accurate. This is no 1. reason I rarely ever use search on Android or Windows. I don't trust it.
I remember wondering at the time: do windows and mac not do enough to help users organize their files, or are the cute little My Documents and Pictures folders that obscure the underlying filesystem already too much?
There is a fundamental impedance mismatch between what hierarchies facilitate and how users think of their files. Users think of their files as having concepts associated with them. e.g. "this file is a photo, about my vacation, and is about scuba" or "this file is a book, about scuba"
The user may attempt to express the numerous concepts they associate with their files in terms of a hierarchy, but chances are good they will fail miserably because hierarchies simply aren't up for the task of organizing even moderately diverse data. Is 'vacation' a subset of 'photos', with 'scuba' being a subset of 'vacation'? Where then does their scuba book go? Is the 'scuba' sub-directory something they must create twice, once under 'vacation' and once under 'books'? Inevitably some concepts get duplicated sub-directories across the system, or the user settles on under-organization. This is because hierarchy isn't up to the task of organizing files in the way humans think about files.
The answer of course is some form of file tagging, so that 'scuba' can be a single distinct group that overlaps with both 'books' and 'vacation' and 'photos', but isn't a strict subset of any of those.
But that is separate from what file paths are for, which is essentially a semantically meaningful unique identifier. If you want to take a photo with the camera app, crop it with the image editor app, then attach it to an email with the email app, you shouldn't have to search through your photos again the second two times to re-find the one you're already working on. There ought to be something equivalent to copying the file path to the clipboard so that you can reference the file you're already working with in another app.
This is close to my core point. File paths and/or file hierarchies are not good for file organization. They have been pressed into this role for historic reasons and out of inertia.
Papering over the problems of file hierarchies by implementing a good copy-paste system is not a good solution to the fundamental problem. It alleviates some problems, but not all. You can conceivably copy-paste a file you've been working on in one app into another, but what if you want to retrieve a file you last interacted with a year ago? How will you find that file?
Under the file hierarchy scheme, in order to retrieve an old file the user must remember the idiosyncrasies of the hierarchy they created ages ago, with many concepts invariably being split into gods know how many subdirectories, OR nearly all of their files sitting in a small handful of directories, unorganized, with little more than the file name to help retrieve the desired file. These are both poor states of affairs. They require the user to store too much extraneous state about the system in their head in order to have any chance of efficiently finding the files they're looking for.
Modern systems have begun to improve on this state of affairs by implementing file searching capabilities that function more like internet search engines than traditional hierarchical directory explorers. In theory the user may be able to simply search "scuba" and the black box file search system may use a variety of methods for pulling up a list of files from numerous different subdirectories it believes to be scuba related. Perhaps it pulls in both /vacations/2017/scuba/neat-fish.jpg and /books/scuba/how-to-scuba.epub because both have the string "scuba" in their path. Or perhaps there is some exotic shit going on behind the scenes and an image classifier was previously used to determine the presence of scuba gear in /Pictures/1002389943-984983-198395.jpg This sort of file search engine is fundamentally an imperfect file tagging system. The tagging in this case is being done automatically in a variety of ways the user may or may not be aware of and understand, and may or may not be able to consciously influence and exploit.
Let's take a step back for a moment and define the problem:
In the mind of the user, there exists a many-to-many mapping between files and concepts. When a user is thinking of a particular file, they have in mind a set of traits about that file. (For example, the user might be thinking of "that picture I took of a strange fish while scuba diving on vacation." The concepts associated with that file might be picture, fish, scuba, vacation.)
How do we get that mapping out of the user's head and into the computer, such that it can be used by the computer to retrieve the files a user desires when thinking about a particular set of concepts?
That's not yet a question with a definite answer. Automatic tagging of files with concepts the user is anticipated to have should certainly play a role. Image classification is heavy, and therefore has privacy implications since that sort of thing is virtually always offloaded to some corporate server, but when it works well it's great. There are easy sources for automatic tags as well, such as extracting terms out of the file path, or extracting date ranges or even geolocation out of the file metadata. These are great, but typically prove insufficient on their own. Asking the user to manually tag their files with the concepts they associate each file with gets you a very high quality many-to-many mapping between files and concepts, but that is manually intensive. Notoriously so. One solution is to amortize it; during file creation ask the user to tag the file instead of naming the file. That's okay, but still not great. The user might be snapping 10 photos...
With searchable tags, or whatever other thing you can come up with which is better than trying to remember a file path. But that doesn't mean you should get rid of file paths, because they're each good for different things and there is no reason you can't have both.
Here's another example. On a desktop you can open a static web page from a local .html file along with all the associated content. You'll have a directory containing an HTML file, maybe some associated .png, .gif, .webm or .js files and so on. A complicated one may have its own hierarchy because it's useful within the context of that document. Then that HTML file is going to have the names of the other files in it, including their relative paths if they're in subdirectories. The same thing can happen with InDesign documents or any other composite document like that.
Now how does the user find that HTML file a year later? Using some kind of tags or search function. But the way the HTML file then finds its associated pictures/scripts/videos is using something like filesystem paths. The alternative would be to combine them together into some kind of tarball, which is what some things do (like PDF), but then that's worse -- how do you edit a photo which is embedded in a PDF? Your average image editor will either not support it or will be inclined to do something horrible like rasterize the whole PDF first.
You're touching on a broader subject than file organization though, and that is humanist software design. Your static web page example is a good example. That's not humanist software design, it's design that serves the computer. When you save a web page you get an html file and a directory next to it that contains the images, css, etc of that webpage. The user is now burdened with keeping that html file and resource directory next to each other for the rest of the lifespan of that [meta-]file.
Consider instead the epub format. It too is one or more html files with images, css, etc. However unlike the traditional local static copy of a web page, all of those files are zipped together and stored as a single file (an epub is a glorified zip file with a special file extension. You can extract them with `unzip`.) This unburdens the user; they no longer have to worry about keeping those files next to each other when copying it, sending it to other people, etc. Epubs are humanist design (and not only for this reason, but I'll save that for another discussion.)
Of course inside that epub is a hierarchy of files. And that's fine. A hierarchy of files serves the ebook reader well. While strict hierarchies are poor for user interaction, they're great for software. The details of a file format need not be humanist because the user is not meant to pick it apart. Of course there may be perfectly valid and common use-cases for the user to pick it apart, to pull images out of it for instance. Software that facilitates pulling data out of documents, into a format that is generally useful to the user, is humanist. Consider your common desktop web browser for instance. It allows the user to easily pull an image out of a webpage by right clicking on it and saving it, or perhaps dragging the image out of the browser onto their desktop, or similar modes of interaction. The user needn't save the entire webpage, then poke through a directory filled with numerous files looking for the image they wanted. (At least, not unless the website and browser are conspiring to behave in a manner that is hostile to the user, for example by blocking right clicking....)
PDFs and PDF readers are shoddy in numerous ways of course, and strict hierarchical file management has done little to alleviate that.
But that's the issue. You can make it easier to use tags, you can make it so that they are what most people use most of the time, but you still want everything to be able to use paths, in a way which is still as universal and intuitive as possible, so that it still works properly everywhere when you do have a good reason to use them instead.
> Consider instead the epub format. It too is one or more html files with images, css, etc. However unlike the traditional local static copy of a web page, all of those files are zipped together and stored as a single file (an epub is a glorified zip file with a special file extension. You can extract them with `unzip`.)
Here's something even better -- what macOS does with applications. You look in /Applications and see a bunch of programs. Those are really directories with the application's files in them, whose names are the names you see but with a .app extension. If you click on one, you don't see what's in the directory, you cause the application to open. But you still can see what's in there, by using the actual path with anything that accepts file paths, and that is still useful. Because sometimes there is a .plist file in there or something else you want to modify, or you just want to see what's really there.
This is better than a zip file because it's still native. You get the behavior you want, but if you want to see or modify what's in there, you don't need to use a special program or go through the extra steps to unzip the file and zip it again, you just access it using the real path. Windows at one point did somewhat the opposite and exposed the contents of .zip files as folders, but that doesn't seem to work as well, e.g. modifications are not permitted or are inefficient or have other issues because you have to repack the whole file with every write.
It's a very compelling idea, but as I said, orthogonal to the matter of hierarchies or tagging. Say for instance you want to edit the .plist file of Blender.app. Where is Blender.app? Probably at /Applications/Blender.app but maybe it's in /Users/zrm/Applications/Blender.app To dive into that file/directory, you must first find it. How the user is meant to find it is the question that needs to be addressed. That's a simple example of course because there are only two likely locations for it (and the later is unlikely), the file/directory you're looking for has a name you remember off the top of your head, and because either of those directories probably has no more than a few hundred entries (probably a fraction of that.) In this case the user of a hierarchical system doesn't run into much trouble because the situation is virtually ideal, but even so a tagging system would have simplified the query. The further you get from ideal circumstances, the larger the gap between tag systems and hierarchical systems grows.
Additional thoughts on record oriented file systems: one example is Files-11 from VMS. An interesting property of Files-11 is that it allows files and directories to have multiple parent directories, which is similar to Unix's hard links except that directories, not only files, are allowed to have multiple parents. This gives the system the same expressive power of tags (consider each full path a file can be found at to be a tag on that file.) This allows all of your books to simultaneously be in /Books/ while still allowing you to have them in other locations like /School/cs/cs101/textbook.pdf However a system capable of expressing these relationships is the easy part. The important part is giving the human users a clean user experience, allowing them to take full advantage of the power of such a system without requiring them to manually create and maintain a web of nested links.
I do have other physical folders, just stored in three plastic bins in the closet. The bins are unlabeled, but I know what each one contains just by glancing at the contents and from there, knowing that my old computer science articles I want to keep folder is in the middle of this particular bin. Again, most of the folders are unlabeled/mislabeled but that doesn't matter to me because I know.
A filesystem can't quite replicate this spatial or looks feature of physical folders. There are also restrictions on what you can name a folder or file. For instance, I might want to name a file "Foo Inc. Invoice, Project: Snafu 3/19" but I can't---on Unix and Windows, the '/' is forbidden, on Classic Mac OS, the ':' is forbidden. Yes, I could place it in the "invoice" folder, or maybe the "projects" folder, or maybe the "foo" folder (or all three with hard/soft links) but now there's some cognitive overhead of just remembering where (unless I use links, but that's a weird thing with no real world counterpart, a physical folder can't exist in three different locations).
The spatial thing is important (but it could be just important for me). I've been using a virtual desktop on Linux for nearly 20 years now, in the same 3x3 configuration. The upper left corner is email; the middle right is the browser. Bottom left is a realtime view into system logs. The middle left and middle middle is where I do most of my development. The remaining spots are for overflow or temporary areas. When I got my Mac at work, I set it up with a similar spatial setup [1]. It helps to keep me oriented with what I'm doing.
And yes, I do know and understand the hierarchical file system, but that I still lose track of files from time to time ("I know I did this at one point---where did I put those files?"). I have 1.3 million files in nearly 200,000 folders in my home directory. It's amazing I can find anything at all [2][3].
[1] It's a linear series of 9 screens, but I still treat it as a 3x3 matrix of screens.
[2] A few weeks ago, I wanted to find the original image I used to make the favicon for my website about twenty years ago. I failed, and started a search with Google Image to see if I could find it (since I originally found it on the Internet). No go. A few days ago I found a folder I forgot about and lo', there was the original image.
[3] I also have 3,000 symlinks, three sockets, one named pipe, and 6 "others" (whatever those are).
That hierarchies can be expressed by tags is easy to demonstrate. Simply tag each file with all of it's parent directories up to root. Implementing hierarchies in terms of tags is not as computationally efficient, so you wouldn't actually write a filesystem in that way. The point is to create a new interface for humans, not for software. When a human has a dataset that is genuinely best organized as a hierarchy, they can express that hierarchy in terms of tags.
Of course traditional file hierarchies implemented in the traditional way, not in terms of tags, must still exist for some purposes. Source code, which requires a deterministic and efficient way to refer to specific other files, is one example. (However the user could still benefit greatly from augmenting the source code tree with tags.)
What I'm suggesting is not that hierarchical file systems be removed from operating systems, but rather that they be removed from nearly all user interaction with computers. The "Save as" dialog should not be exposing the hierarchical file system, at least not by default. Ditto the "Open" dialog. Hierarchical file managers like Finder, Explorer, Dolphin, Nautilus, etc should all be revised to be foremost file tagging systems designed to aid the user in managing and querying their tags. The "Desktop" should not be a directory on the filesystem, but rather a tag (or even a complex dynamic query.)
Why would someone think of files like that? I don't organize physical objects that way. My books are on my bookshelf and my pictures are in albums or frames. Why would a computer be different. I wouldn't store a book about scuba diving with or relate it to my vacation pictures of me scuba diving in any way in real life, why would I do this on a computer?
If I had a collection of books on my computer and pictures from my vacations it would be stored the same way I would do it in real life, keep the books together organized however and keep the pictures together organized however. The topics of my vacation pictures and my books have really nothing to do with eachother, even if they happen to be related.
What you describe sounds like the very opposite of how i'd want my files organized.
You don't put every single physical item you have relating to scuba into one big bucket because in the physical world, putting something into one bucket precludes it from being placed into another bucket. When you are organizing things you have to anticipate your most likely queries in advanced. So maybe you have one shelf for science fiction, and another for marine wildlife, and another for all your programming language books. For a while, this works well enough. One book can't go on two shelves, but with few enough books that's not a deal breaker.
However, when your personal library grows large enough, this system rapidly becomes impractical. At this point, the librarian resorts to creating a card catalogue, categorizing books by author, subject, etc. Books which have numerous topics have numerous cards in the card catalogue.
Since this is the 21st century, card catalogues are now digitized. The digitization of card catalogues saves space, but more importantly it facilitates more powerful queries. You can grab two different stacks of cards, relating to two separate topics, and instantly find the intersection between them. That is, the list of books which appear in both stacks. This greatly reduces the number of cards you must look through to find a book that you're quite certain is in both of the stacks. For instance each stack might have a thousand cards, but the intersection of those two stacks might only be 50 cards. That's 50 cards you have to search through to find your book, instead of a thousand.
A file tagging system is a digital card catalogue for your files. And as librarian of your library, you can decide which subjects warrant their own tags and which don't. What you don't have to do is decide ahead of time what sort of queries you want to facilitate. And it's no longer important to keep your collection of books and photographs separated. If you want a book, you intersect whatever you're looking for with the card stack of all books. If you want a photograph, you intersect it with the card stack of all photographs. If you have a book of photographs, it could even be in both, should you want it to be.
When i look for things on my computer, i don't have a vague concept of an idea of a thing i'm looking for, i look for specific things for specific purposes. Why would i need everything on my computer related to cats showing up if i'm looking for say, a cat sprite in a game i'm working on vs a picture of my cat or say a cat meme? I have no need for the other two things if i'm looking for one of those things. Yet in your system all those things and more would show up should i search for cat. That's pointless. I'd rather navigate to my programming projects and assets folder for my cat sprite, and go to my pictures folder for my own cat or meme cats. There's not many situations where i'd ever need all three at once.
For a library or massive database, sure, a file system may be insufficient. But as system for organizing things i need and use for specific purposes, it's not ideal.
What you're describing is that this sort of system excels at. By describing the properties of the specific file you're looking for, the tagging system can locate it very rapidly. Without a tagging system, knowing the file you're looking for is like knowing the bookshelf your book is on. If the book shelf is small, you can look at each book in sequence and find the one you're looking for. When your bookshelf is very long, it pays to reduce the set of files you're looking for.
>"Why would i need everything on my computer related to cats showing up if i'm looking for say, a cat sprite in a game i'm working on vs a picture of my cat or say a cat meme? I have no need for the other two things if i'm looking for one of those things."
If you have a single cat sprite, and search the intersection of 'cat' and 'sprite', then that single cat sprite would be returned to you.
Consider instead you have in mind a particular photograph of a cat and a dog, on a car. Perhaps you know you put that image in your cats directory, which has a thousand images because you're an avid fan of cats. To find that particular cat image, you'd need to search through a thousand images sequentially, unless you happen to remember the precise filename of that single image out of a thousand. Thumbnails will help, but that search is still going to take way longer than it should. If your collection of cat images is properly tagged, then you can instantly get a list of the intersection between cat, dog, and car. That list is going to be much shorter than 1000 images. It will take you seconds at most to glance through it and find the precise image you were looking for.
With terabyte harddrives being dirt cheap commodities, there is no real reason the average person couldn't or shouldn't have hundreds of thousands to millions of files at least. The reason most people don't is because with the organizational software currently available to them, (e.g. windows explorer) there is no feasible way for them to keep that many files organized. There is no good reason that should be the case.
Fewer permissions needed for app private data, automatic clean-up of the files for an app, implied better security of said files because they're in a sandbox, controlled access to certain file data (location info in photos is only visible to the app that is the device default for photos), etc, etc.
And that's not even getting into the security issues with a shared filesystem, where a single evil process can access all your data.
They're leaving no way out, and making things like "Syncthing" and general file managers really hard to continue operating.
That's becoming the answer with everything on Android, for anything useful you want to do, you need to root the phone. The stock phone is becoming just good for running Facebook and Candy-crush.
A communication-only device that can take photos and browse the web is very useful, but I think it will lose market to a proper computer every time.
It might not. Every phone company has strong incentives to optimize their offering to the lowest common denominator. Majority of people are not tech-savvy, and they have no context for what computers are capable of and how those capabilities could be applied to their lives, so they simply choose from what's being offered by hardware and software companies. People who care about this stuff are a minority, and there's not much money in catering to them.
If computers could be bicycles for the mind, the modern trend is making people sit on their ass instead, and consume what's delivered to them.
Because files don't always have a clear ownership. I have a folder full of photos and I don't want any particular application to "own" them. That a file corresponds to a concrete app that owns it is a lie, that's being pushed hard by mobile OSes.
2) Companies make more money by having you store all your data in The Cloud: you have to pay (somehow) for storage on their servers, they get to comb through your data and mine it and use it to advertise to you, and the cellular companies get to charge you for access to your own data because you have to constantly transfer it wirelessly instead of keeping it local.
So no redundant obsolete copies. This mechanism has been in Android for years now.
And for files that might be opened through multiple apps (say you downloaded a picture - now you could reasonably launch a photo editor for that file directly through your browser, or through a file explorer, or your gallery or ...), each sending app will generate its own URI and the receiving app has no guaranteed way to decide whether those URIs all refer to the same app or not.
that should read "whether those URIs all refer to the same file or not."
That's not how it works. It doesn't go and uninstall every copy.
Nope, No problem at all.
Big tech wants you to not own anything, because in that case you'll have to subscribe to everything. If you can't subscribe or you don't have enough money to subscribe they'll make it "free with ads". But one thing is a no-no -- you buying and owning any content.
My most used tools are Solid Explorer, Termux, and Syncthing.
* Apps are only allowed to access only files that the user explicitly allows them access to. (No more Epic games launcher slurping up your Steam library information)
* Apps can present file-like objects to the file picker and have them work transparently. (No more one-off filesystems to just forward an API call)
* Apps don't have to know anything about permissions. You just get a blob of data.
> * Apps are only allowed to access only files that the user explicitly allows them access to. (No more Epic games launcher slurping up your Steam library information)
This assumes that all content you possibly want to open in a different app always consists of a single atomic file.
Unfortunately that's not always the case, though. If you open a HTML file from your storage, you'll likely want your browser to be able to access the accompanying images, style sheets, other locally linked files, etc., too, but under Google's file access model that's not possible. Or say you open a video file where you've also thrown some subtitles into the same directory - unfortunately your video player will only be able to open the video itself and never even learns about the subtitles.
For a small demonstration, just copy some archived web pages to your storage and then try using the built-in file explorer (which uses the officially sanctioned way of content://-URIs for launching apps) to view one of those HTML files in either Android's mini HTML viewer app or else Chrome and marvel at the missing images, broken styles, non-working links...
> * Apps can present file-like objects to the file picker and have them work transparently. (No more one-off filesystems to just forward an API call)
> * Apps don't have to know anything about permissions. You just get a blob of data.
Unfortunately it also completely hides the underlying file system, so even if the file in question is one that a) is actually sitting on the local storage and b) is stored somewhere where the receiving app would have access permissions itself anyway (because you've explicitly allowed that app to access that part of the storage), you still have no official way to get a reference to the original file. This is a problem because if the receiving app could open the file (and accordingly also its companion files) using its own permissions, it could in fact avoid the issues resulting from the first point. As it is, you're somewhat stuck, though.
The sales figures disagree.
In this case, the lateness of the product, the continual burning of their phone platforms, anticompetitive behavior of Google and some of its associated companies, carrier disinterest, and a lackluster marketing campaign are among the reasons it failed.
I doubt you will find many people who tried or used the phone who didn’t like it.
You can still see this in most reviews, too - reviews of Windows 8/8.1 are generally pretty negative, while reviews of WP 8/8.1 on the same site are positive to glowing.
Windows Mobile 10/Windows 10 are the only ones that are nominally the same and still are in fact very different.
Again, if you talked to people that actually picked up and tried (or bought) a Windows Phone, they were almost universally very pleased with the phone UI and OS. The single biggest complaint you will see is about the app selection.
And please don't be condescendingly academic about WP/W8 distinction. The "ugliness" of UI people here talk about is present on both platforms and you still have to do some work to hide it on W10 (e.g. manually unpinning tiles from start menu after each upgrade, confusing system settings, disjoint set of options in old vs new UI etc.).
> And please don't be condescendingly academic about WP/W8 distinction. The "ugliness" of UI people here talk about is present on both platforms
I googled "Windows Phone 8 review". This is typical of the results I get.
https://www.cnet.com/reviews/windows-phone-8-review/
Windows Phone 8 makes significant changes while remaining true to its core. It's sharp, colorful, clean, and simple, but also hip and a bit exuberant. New features include a surge of NFC actions, greater customization, and a heavy peppering of more-minor additions and adjustments; yet it's the tile-based interface that continues to be the operating system's most distinctive and defining characteristic.
The UI is virtually always called out as great and great looking, even if the reviewer ends up not liking the rest of the package.
I felt like the tiles displayed the right level of information where I could quickly glance at my phone and see if there was anything important that needed my attention, while helping to reduce the mindless time I spent getting distracted by noise.
When I was using my Windows Phone it felt like the UI was built to decrease interaction with the device, which was a positive to me. It was trying to get the right information in front of me so I could get back to being detached from the screen.
But that is a sample size of 1.
The other thing that killed them, as many have noted, was the lack of apps. That's because they were too late mainly; they were a me-too after iPhone and Android had already established their dominance. What app developer wants to spend a lot of time and resources developing a 3rd version of their app for a new platform that no one is using yet?
It did alright in Europe but overall, the Windows Phone campaign was inexcusably mismanaged to such a degree that it seemed deliberate. It felt abandoned almost from day one. It was unlikely you'd see one anywhere, in any store, because it'd been relegated to retail backwaters like the Microsoft Store.
It was frustrating to watch. Essentially the whole Zune thing on replay. Microsoft does not do a good job of presenting a united force to get a product in front of the eyes of consumers or generating any sort of hype.
And then they ran Nokia through a corporate shredder, just in case you were worried that Windows Phone might have a future.
From what I remember in the US, the phone stores just weren't interested in pushing them too much, for various reasons. That's not MS's fault.
Maybe you didn't think they were ugly, but a lot of people did. Aesthetics have never been MS's strong suit, nor has naming (their names are always horribly boring and unimaginative, unless they buy it, e.g. PowerPoint or Excel).
MS also had a bad reputation because everyone knew they made the OS on their home and/or work computer that crashed all the time. XP will still in use at that time, remember, and 95/98/Me weren't that far in the past at that point.
MS also has a bad history of abandoning their products. You mentioned Zune; right before that, they had "PlaysForSure", which didn't "play for sure" because they abandoned it and all those customers were screwed. On Windows Phone, people who bought the earlier versions were screwed because they were incompatible with the later versions. (IIRC, this was a big problem because the apps were incompatible between the versions, and this made the app store problem even worse.)
Sure, there was a lack of apps; but it wasn't all because it was too late; Windows phone 7 wasn't _that_ late to the game, and there's value being the only app for X on a platform, even if it's the smallest platform. The problem was your windows 7 app didn't work right on 8, and you probably should rewrite it again for 8.1, and you definitely need to rewrite it for 'Universal' Windows Platform for 10, except that's a waste of time since 10 never got anywhere close to the number of users as 8.
If Microsoft hadn't effectively killed Windows Mobile 10 by merging the desktop and mobile teams during development, and ended up with a solid Windows Mobile 10 release at launch, they would have been able to continue as a third platform. Supporting WP 8 devices upgrading to 10 and continuing to release lower end devices on 10 would have helped get existing developers to update their apps for 10. Having a decent browser would have helped, but Microsoft was playing the 'pretend to be iOS' game too hard, and blocked browsers from the store until it was too late; Firefox wanted to release for WP, but Microsoft said no, and IE/Edge are IE/Edge.
Given all of the things Google is doing to try to rein in apps, like Doze and this storage api revocation; it would be nice to have an option that isn't iOS.
WP 8 may have been ugly, but it was functional, and had a dark mode _everywhere_. The better tiles were really useful for getting the right amount of information, and because they were a critical part of the UI design, most apps supported them, unlike launcher widgets which are pretty hit or miss. Number badges require you to go in and reset the count to zero or they don't provide a useful signal; seeing the last message lets you delay it to later.
Apps were part of what killed Windows Phone, but I also think they released their OS with too little built-in features. My brother used to own a phone with early Windows version; it lacked a lot of small conveniences and tweakables that were available on contemporary Android phones. I vaguely recall sharing media with other devices was a problem; not unlike how it's with iPhones.
https://news-cdn.softpedia.com/images/news2/Windows-Phone-Ap...
If they had that from the day one, it could have ended up with a lot less resistance (just the ugliness of the default palette was unbearable; they must have hired an expert for achieving the most negative impression with those original tiles/colors).
And until end of this year they will sum up more updates than most of Android devices combined, and VS offers a much saner development environment.
What the vast majority of people also don't want to do is spend time and effort dealing with malware. Hence the success of locked down systems.
In frustration and at 25% or less of the actual capability, because of stupid design choices that destroy interoperability. This is mostly a consequence of an app market of selfish independent actors, but at least the operating system could encourage more interop, instead of trying to destroy it.
Make something that will run the same apps, on the same hardware, but put the user in control of the thing. Then add all the interesting features you wanted to put in your independent system.
Which is easier in this case because it's possible to fork Android and start from there. The major problem seems to be the driver issue on mobile. The drivers are blobs tied to a specific kernel, which makes it hard for people to try out the new thing on their existing phone, which suppresses adoption and participation. And that's also the thing that prevents you from even upgrading your old phone to a newer version of vanilla Android.
So it seems like what we badly need is a solution for that.
And we've seen that apps that are trustworthy can be bought and sold, sometimes by companies that are very untrustworthy.
When I used Android, I just didn’t install things unless I really, really wanted them, and they were popular enough that I figured security researchers would likely be looking at them closely. (Which, of course, was a great incentive to keep using Google’s ecosystem for everything.)
I tried iOS a few years ago, and one of the big differences is that I’m a lot more confident about trying random apps; I know there’ll still be shady apps, but Apple’s vetting and the iOS security model give me a lot more confidence. I’ve installed (and paid for) a lot more apps as a result; my phone’s much more usable to me.
Somehow we're not discussing prohibiting filesystem access for personal computers? Why is this an issue for smartphones, a.k.a. a pocket-sized personal computer?
If Windows had proper filesystem sandboxing enforced on applications, ransomware would disappear overnight
It is just that now there is a lot more control to insure that the user is aware of it, and some new technical limitations.
Its disruptive, but not nearly as limited as iOS.
The content jails in iOS made the device into a media consumption toy, rather than anything productive.
Everything is technically complicated on Android, I've also worked into customizing ROMs, trust me, Android kernel & top layer are so clunky that it's even a miracle that the phone is switching on. There's really nothing we can save from this garbage system. Sorry for the Android fans reading this but that's truly my personal opinion after digging into it for a few months. it's just piles and piles of hacks as far as the eye can see.
This would still be the case if you put Windows 10 desktop on a phone. The problem is that even though the Windows desktop has a healthy app ecosystem, these apps work poorly on touch devices. This is true for touch devices with large, high-quality screens (various desktops) and for smaller, more portable, but still high-quality screens (like the Surface). Rewriting an app to work well with touch turns out to be an enormous amount of work for the typical Windows app developer. This is true in the ideal case, for C# devs working with WPF/XAML, but it is much worse for devs working with older apps... WinForms, MVC, etc.
Without the desktop apps, you're left with something that is basically an also-ran in a market saturated by iOS and Android. In the meantime, the desktop experience is still not completely touch-friendly and has suffered from a fair amount of design damage in the process (e.g. two control panels). Any developer that would go through the process of getting their existing Windows app working with a touch UI is going to evaluate porting to iOS or Android, and probably prioritize those options.
[Edit]: I should also add that I really want the opposite of what you ask for. I really want my Android apps to also be available on my desktop PC. It would be really cool if I could plug my phone into a clamshell laptop-like device and have a big-screen experience.
It was exactly what you describe now.
I am still sad about that.
https://en.wikipedia.org/wiki/Ubuntu_Touch
On the upside, this is still being worked on. The UBports community is still active, and KDE has been refining its plasma mobile interface. Purism's librem 5 should be convergence-capable.
Window toolkits are also being developed to help create responsive applications: Kirigami and libhandy, to name a few.
On the non-opensource front, there is also Microsoft's UWP, and samsung's DeX is showing some promise.
We're getting there, but slower than anticipated. The EOMA68 is also a promising concept, though slightly different, and more similar to what the parent describes.
Never happened, and instead we got 19 flavors of "cloud sync", which doesn't solve the problem and has nasty security implications.
I still want my portable ~home.
A high quality flash drive[2] boots up instantly and loads apps instantly. I can't work on a 3" screen and don't want to carry around anything any bigger. So for me this is a better solution than a docking station for my phone.
[1] https://wiki.archlinux.org/index.php/Installing_Arch_Linux_o...
[2] https://shop.sandisk.com/store/sdiskus/en_US/pd/productID.52...
Also, in the case of public computers, the risk of keyloggers means you cannot trust the computer even if you boot your own OS.
> risk of keyloggers means even if you boot your own OS.
While it's likely the OS of some of the machines I used were infected, the odds of them carrying firmware based backdoors was not a concern. The odds of getting dengue fever were far more likely than a hardware level hack. Those attacks are very hardware specific limiting the potential for widespread infection. At the time Snowden was still fresh on my mind. So I was more concerned with the NSA was sucking down all my emails / cloud data. There is only so much you can do.
Had I been using the OS on the cybercafes, I'm sure my risk of getting keylogged would have been 1000x more than using my own OS on their hardware.
How many of their users bring their own OS on a flash drive? In my travels, I only met only 1 other. One. He was running Tails. And as I said the chains with their management software and BIOS lockdown don't even allow this. So we're talking mom and pop cafes.
Now do you think those small time owners are going to spend their money to add this additional cost to spy on that one traveler who has his own OS? That make zero sense when they already control the OS and network. So much easier to spy on customers on that level. In that case, VPN + my own OS circumvents them.
Your paranoia only makes sense if I was going to DEF CON or some kind of a target of state level spying.
Pros:
* Unlocked OS
* Runs Linux
* Support great camera
* Good gpu; HDMI port
* "Portable"
Cons:
* No cellular radio
* Runs ubuntu
* Have to find a 19.2V battery solution
How do you imagine this would work even in theory? Running two OSes side-by-side (one when in phone mode, one when in desktop mode?).
Or running two largely incompatible desktop shells with largely incompatible interfaces for multiple apps (touch-optimised programs are very different from mouse-and-keyboard-optimised programs)?
For applications there is lots of work to make it really nice. Putting mobile apps on "desktop" can be done, while user interface will be a bit strange. But that's a thing which needs time. Microsoft tried that by pushing mobile on desktop, but they didn't have the mobile story. Apple has notable Userbase on both.
Userbase has nothing to do with that.
Found the (ex)-firm: Oqo.
https://www.ft.com/content/5241d778-56d5-11da-b98c-00000e251...
https://en.wikipedia.org/wiki/OQO
https://www.slashgear.com/ces-2009-oqo-model-2-umpc-hands-on...
http://cf9e233f57bd4ae986b3-d4e74cbd2619c9a623339399e96f346b...
Sadly WinPho was a distant third in a two-horse race.
As long as I have a bluetooth mouse and keyboard, I'm having the full desktop experience from an iphone that's 3 years old. I can even cast my phone to a wall sized projector which is really fun. Only caveat is that it requires a very good internet connection.
Each time your app opens and reads a file, the application on other side of ContentProvider can monitor user activity down to number of bytes read. Each time you open a directory, that action can be noted. If anything, that sounds like a privacy nightmare, and will undoubtedly be exploited.
[1]https://play.google.com/store/apps/details?id=com.estrongs.a...
Is the paid version much better?
It's like a completely different app, all the cruft like ads and pushing other apps is completely gone. You're just left with all the good stuff and those features generally all work well.
(I am not affiliated with the creator)
I like its column-based view of the filesystem, and the wifi server that you can open a web browser to and upload files from your laptop/desktop.
Some of the features are paid, but frankly $5 for an app really doesn't bother me much as I try to donate at least that to the different open source projects I use a lot.
[1] https://lh3.ggpht.com/-aGrlHAFIEPCk-tusiw91bH6sn-YfzS5pNo-ng...
That said, once I tried copying/moving files around, I was sold on the 2-column layout. I recently got a new phone, which meant moving my custom ringtones and notification sounds to their correct locations. With Google Drive I downloaded them, then using X-Plore I moved them to the ~/Notifications and ~/Ringtones folders. That was fairly easy to do - you find the destination in the right hand column, then swipe back to the left column, select the files for moving, then choose copy/move.
It's kind of like the column mode in Finder on OS X, which I really wish I had on Windows 10.
I've used Amaze File Manager ever since, and I have no complaints.[2]
[0]https://www.androidpolice.com/2015/11/28/after-adding-a-bunc...
[1]https://www.androidpolice.com/2016/05/10/es-file-explorer-up...
[2]https://play.google.com/store/apps/details?id=com.amaze.file...
* Packing/unpacking 7z and Zip/Zip64 (splitted-encrypted), TAR, TAR.GZ, TAR.BZ2, GZIP, BZIP2, XZ, WIM, Lizard, LZ4, LZ5, Zstandard.
* Root access for all advanced operations.
* SAMBA, FTP, SFTP, WEBDAV supported as well.
* Intuitive, unlimited tabbed browsing.
* Very pleasing, nice-looking, easy to use interface (I know this is silly, but as much as I like Total Commander which is good I always felt it's interface was a little clunky.)
* Developer is very active and receptive to feedback.
Give it a try, it's free on XDA with a paid version on the Play Store[1] with at the time of writing, only 5 and 4 star reviews.
[0] https://forum.xda-developers.com/showthread.php?t=1523691
[1] https://play.google.com/store/apps/details?id=com.mixplorer....
I think I could build it from source but I don't have an Android dev environment anymore so I installed the app from Google Play. It asks surprisingly few permissions: read/modify/delete content on the SD card and access to fingerprint hardware.
Amaze is a decent file manager, follows material design, free/open source and available on F-droid.
It also includes an ftpd so it's pretty easy to connect to it even from computers you can't install stuff on.
That handle is probably good-enough for basic file management operations, like copying, moving or renaming files, but (from what I've read) if you want to, say, jump to the middle of a file, such as to read a specific file contained in the archive or seek to a specific position in a music/video file, it becomes very inefficient. If you want to read/write from a database (and need that database to be easily shared between different apps), then you also have a problem. If you use an app like Termux, which exposes the file system to standard unix utilities, and want to directly manage all your files with them, you're pretty much out of options.
Re Termux, I actively don't want any app on my phone to have direct access to the rest of the files on my phone. The fact that desktop terminal apps (cmd.exe, Terminal.app, xterm, etc.) require this access is the root cause of a bunch of security difficulties in desktop OSes that are impossible to solve in a satisfying way. I want a little workspace (potentially multiple workspaces) for stuff where a terminal is the right way to work, but I don't want the ability for any app to cd into my Signal storage directory or my email client config directory and edit files there.
As a result, I use iOS. If Android will get me the same security design plus the ability to call fork() so Termux works, I'd consider switching - it sounds like that's what they're doing.
If you don't give Termux the "storage" permission, then this is exactly how it works now.
> Signal storage directory
Signal stores its data in its private app directory, which is not exposed to either any other apps, even if you give them the "storage" permission, or to the user via MTP. The only exception is the optional back-up, which is stored (encrypted!) in the public app directory (accessible to MTP and apps having the "storage" permission), so that you can copy it to your next phone. (AFAIK Signal on iOS doesn't give you this option...).
> email client config directory
K-9 mail also stores its data in its private app directory.
OTOH files that are not super-private, like books, audiobooks, music, maps or flashcards can be stored where they're easily accessible, manageable and processable by multiple applications (but even then, only applications that I grant the requisite permission).
It's ridiculous that a supposedly sandboxed text editor would have access to all your photos, for instance.
Apps should only have access to their own private storage and to data that the user has explicitly picked from a file picker or similar UI, which is what this update does AFAICT.
It seems a serious mistake though to not affect apps installed on upgrade and to disallow access instead of just providing a virtual private copy of the external storage for each app (though the latter is not clear from the article).
I also use an open source file manager app to access files on both internal and external storage. I need it to access all of it.
I understand I'm not the typical Google user as I'm logged in only in Google Play and Google Drive, which I use for work and not for backing up stuff. However if they turn Android into iOS maybe I could finally buy an iPhone SE when the last small factor Android phone dies. Not really, because that would leave me with a much more closed down environment. Alternatives? Maybe a Linux phone if there will be something around, but I'll have to keep using an Android anyway, so going around with two phones, which is worse.
What Google should do is give an option to lift all walls between applications (or root the phone). Void warranty and the likes, it's fine for me. I'm replacing all closed source apps from untrusted parties with open source ones anyway.
FWIW Google Photos does exactly this. It even scans your directories and pops up a prompt "Hey, I found a new folder with images, want me to back it up?". I really wonder how this will turn out...
Do you have any evidence that that's the approach they plan to take here, or is this just a lazy accusation backed by nothing but cynicism?
I'm not a smartphone power user (RSS, email, light internet), so I was really hoping FirefoxOS or the Ubuntu phone would generate some traction.
According to their privacy policy, they collect all the "data needed in order to improve their services and offering" and "can provide these data to third-party" for that purpose.
Paying for an app on android platform is no assurance the app actually respect your privacy.
Doing stuff like this is a promise that their less-power-user-y tools will do everything seamlessly, a promise they have repeatedly failed to deliver on. Getting Google Music to play nice with a my SD card was a nightmare until I gave up and just copied files over the network onto it directly and told it "search this folder".
I really hope that KDE Connect will be compatible with the new system. I use it almost every day to access files on my phone from my PCs.
They actually had to do that to expose all possible storages on Android - including OTG mounted drives. Apps that didn't do that will be broken now, but they weren't doing the right thing either way.
https://developer.android.com/preview/features/roles
Is it a sign that isn't set in stone yet that it might be pushed ?
Most of us are probably willing to pay a premium for this. Librem 5 Looks promising, but its hardware is not as good as the popular flagships.
https://puri.sm/products/librem-5/
I hope this isn't forced on everything and there is a flag somewhere in the settings that i can use to indicate which applications i trust that can have access to everything like before.
People like you can root your device.
And lose access to Google Pay and WideVine DRM validation (Netflix)?
The only difference now is that apps won't get full, uncontrolled access to all your personal photos, documents and app data without your explicit consent and ability to limit them.
I can only hope that Microsoft "every random binary has full systemwide r/w access" Windows will follow shortly!