Yep, even more importantly, the OPs problems are a very general ones with the way the Internet and the whole cloud thing works these days. There are a ton of cloud services that let you enter data in, but there are only a very tiny few that actually let you get the data back out of the cloud again. It's a problem that isn't just limited evil cooperations, many open source project hosters for example suffer from this as well and provide only partial data export, which becomes a major annoyance when you want to move data from one host to another. Essentially proper data import and export is at best an afterthought, if offered at all, while it really should be a standard feature from every service handling data.
The biggest problem with complaining about GUI is that none of the problems are really GUI specific, they are specific to bad GUI implementations. Searching for files for example has been getting worse and worse with every Windows version, back in Windows95 days on the other side it was great:
1) Hit F3 to launch the search dialog (no need to specify directory, as that comes from the folder you are currently in) 2) Type search pattern (limit by date, filesize, filecontent if you like) 3) Start search 4) Observe the results and do something with them (delete, copy, etc.)
It was faster and more comfortable then 'find' as it gave you visual confirmation of what it was doing and gave you the option to subselect and sort the result. Shell is only easy when everything fits into computer readable patterns, if you ever wanna delete some photos and want to have a visual thumbnail confirmation that those are the right ones, classic shell isn't all to much helpful.Equally it is all that helpful if you only want to toy around with some files in the results, not all of them. And that shell only gives you text, not data, also leads to a lot of problems (i.e. half the shell scripts you find will explode when somebody put a newline in filename), a GUI doesn't have those problems, of course a more modern shell won't either, but those aren't exactly part of the classic Unix toolbox.
The tragic part of this whole depate is that it is really missing the point, Shell and GUIs are not opposites, they are both part of the same interface and there is absolutely no reason (aside from messy historic ones) why they shouldn't be able to work together. "ls" for example should give me a list of files that I can click and move around like everything my file browser would show and equally whenever there is a textbox or listbox in my GUI I should be able to grep and awk on it. Yet no modern GUI really tries to bother with that stuff, they are all stuck in the mindset that command line is evil and not worth bothering with. While command line people get all agressive when somebody mentioned that the world has evolved in the last 30 years and serial terminals are no longer state of the art.
That's actually a large part of the benefit of native applications.
That would only be a real benefit when the available native widgets would be more advanced, but they are not, they stopped developing new stuff 20 years ago, thus you are stuck with list boxes, menus and a few buttons. Take an email or usenet client for example, most follow the three pane view, threads on top, group view on left and a message view on the bottom. Sounds nice in theory, in practice that interface however is pretty bad and the way webpages like Slashdot or Gmail present threaded discussions, with all the posts fully visible in the tree itself is far more readable and requires far less clicks then having tree and messages separated into different panes. Native GUIs also have a lot of issues with basic things such as selecting text, which is almost always limited to a single widget, tough luck if you want to select subject and body of an email and the subject happens to be in a separate widget. Even worse, a lot of text in non-user editable fields is often not selectable at all.
Consistency is of course a nice goal to have, but with current day native GUI widget it just means that you are incredible restricted in what you can do with the app and how you can present information. There is of course the easy way around that in native apps by using custom widgets, but then you lose all consistency and are back to what webpages do.
Now don't get me wrong, the way webpages do GUI isn't pretty either, far from it, but native GUI widget really aren't the solution, not even close.
A large part of the problem with "running applications natively" is that the native programming interfaces aren't really build to handle the kind of applications that run on the web. How would Wikipedia look as a native Gtk+ app? How would Facebook? It's kind of hard to imagine that type of applications stuffed into a classic GUI toolkit. Of course it could be done, but you would probably end up doing it by embedding a HTML widget and then you are basically back at square one.
That of course doesn't mean that there aren't some web apps that would work much better natively, but overall the native GUI interfaces haven't really evolved much in the last few decades and the freedom that HTML gives has allowed a lot of applications that would have never evolved in a normal GUI landscape constrained with menus, toolbars, listboxes and other basic widgets.
How sure are we that the speed of light in vacuum is really the maximum speed of light? One random idea that comes to mind: What we consider vacuum might not be as empty as we think, it might be filled with some kind of dark matter. Light traveling through matter is slower then light in a vacuum. Thus light traveling through our not-quite-vacuum is slower then the actual speed limit of the universe. Neutrinos might not interact with dark matter and thus get a little closer to whatever is the absolute speed limited is. The problem would thus not be that C is wrong, but just that it's a little bigger then assumed.
Of course that's just a crackpot idea, I have no idea what I am talking about.
All the problems arise from the use of human beings in the design, implementation, and maintenance processes.
The problems aren't humans, but the systems in which they have to work. Just like any mechanical or computer competent, humans tend to fail from time to time and just like with any other failure you can prevent that from causing catastrophic failure by building redundancy and checks into the system. Those redundancies and checks of cause have to be forced by regulation, as nobody is building them in when they can save a bit of money leaving them out.
If the banks would really care about those things they could install video surveillance. Take a reference picture of the machine, compare it with how the machine currently looks, if objects are out of place, give alarm and lock the machine down.
The problem with all the monopoly regulation is that it only triggers when you already have a monopoly, it doesn't nothing to prevent one from forming. Thus Google might get into trouble for things that all their competition are doing as well, because they (almost) have a monopoly in search.
Rasterizing is O(N) in nr of triangles. Ray tracing is better than O(logN), approaching O(1) even.
That's only really true for theoretical best-case scenario for raytracing and worst case for rasterization. In practice things look very different, as any real world realtime rasterisation engine will do LODs, tessellation, octrees, occlusion queries and whatever to drastically cut down the triangle count they have to render in rasterization, make it no longer O(N), but something much smaller. Equally O(logN) is only true for static scenes, when you have dynamic ones things look quite different as you and you have to include the cost of building your space partitioning into the whole thing.
And in the end, raytracing or rasterization is really not issue, the interesting thing is how you space partition your scene, as that will have a far bigger impact.
PopCap Games, the Seattle maker of Bejeweled Blitz, is funding the research with a $10,000 grant.
And not so long ago there has been a similar study into the Brain Age games, which basically showed that playing Brain Age makes you better at playing Brain Age, but doesn't really transfer into other areas.
It's free advertisement, you wouldn't have this Slashdot article when it wouldn't be for recycling an old games name and you wouldn't have many other gaming news articles either.
Speaking about radio waves, I always have a hard time visualizing how they fly through the air, what shields them, what reflects them, what is transparent for them, etc. So does anybody know images that demonstrate how the world would look like when seen with radio waves instead of regular light, how a room would look like just illuminated by your WLan router? For IR one can find a few nice pictures such as these, but for radio waves I haven't been able to find anything, aside of course from astronomy pictures, but I am looking more for everyday life.
PS: I know there are issues with resolution that would make a regular "photo" impossible, but putting in some equations into a raytracer might be doable.
to simulate motion blur, but I don't know if any do.
Pretty much all modern games use motion blur. Some of course use it better then others and it is often not quite as high quality as one might want it to be, but motion blur itself is almost everywhere these days (most noticeable when swinging the camera around in a third person shooter).
The Wiimote is an absolute pointing system, not a relative one. It is just a very bad absolute pointing system as it only has two dots for reference, not the three or four that it would need, and thus gets mis-calibrated the moment you move its position. Of course it also doesn't even allow real calibration to begin with, aside from the "Sensorbar above/below TV" setting (some games go a little further).
Interestingly however the Wiimote actually can actually detect four dots, it's just that the sensorbar only provides two, so homebrew software and another sensorbar should give you proper aiming.
The power glove used ultrasonic transmitter, triangulation and the time it took the sound to reach the mic, the Wiimote works with LED lights and a camera. So it's not really the same. A much closer match are however lightguns, they have been around for ages and the later models, that worked with LCD TVs also used LED markers.
LOL. Just from curiosity, since I'm seeing you a tad worried, what is your rate "page-flicks per seconds"?
When it comes to reference books, something like a 100 page flips per second isn't that unusal to find the thing you are looking for. Even a fast ebook display is no better then something like 2 or 3 page flips a second, which is perfectly fine for reading a book, but way to slow for browsing a book. Even your average PDF reader on a PC has a hard time coming near to a real books performance, let alone the tactile feel of it (pages you already read are easier to find again, then pages you haven't touched, thickness gives indication where you are in the book, etc.).
eBooks have a lot of advantages, I love that the page is always flat, not warped, that it stays open without any extra effort, that you can carry around hundred of books, etc., but the tactile browsing that paper books allows has yet to be matched by any electronic reading device. It's however not an unsolvable problem, intelligent bookmarking, keeping track of which pages have been read, zoomable-interfaces or simply analog buttons for moving forward and backwards through the book could go a long way in either matching or surpassing the experience of a real book.
Applications don't have full access to the user's system now, do the concepts of UAC and sudo completely elude you?
Under those the amount of access that an application has to the system is still far to huge (i.e. everything the user has access to, only root/admin are forbidden).
I'm not anti-sandboxing because in some places it makes sense - like in the case of JS and Flash
So how exactly is running a random game as.exe any different then running it as Flash or Javascript? The implementation differs, the purpose of the application and in turn what it should and shouldn't be able to do to the users system is exactly the same.
So by your logic it would be totally ok if every Javascript and Flash app had full access to the users system because running untrusted application isn't a problem?
I would be hopping mad if my (paid for) business webmail provider suddenly decided to do some rifling through my email for their own purposes, as that is not what I agreed to.
It's not quite that simple. If you use your paid for business webmail account without privacy invasion and then mail a GMail user, then Google suddenly has a mail from you that it can sniffle through. If you happen to mail a lot of Google Mail users, they might end up with quite a few of your emails and a decent personality profile even so you never had a Google account.
The problem with privacy invasion in communication is that your privacy can leak at both ends and you generally only have control over one.
And this wouldn't prevent that because already users will grant an application whatever privileges it asks for.
Viruses and malware spreads exactly because on todays OSs there is no asking for privileges, apps just do whatever they want without the user ever having a chance to intervene or know what is going on. But hey, you don't consider that a problem and totally ok. Fine with me, it looks like I can't argue you out of your Win95 mindset.
And when has this ever happened to you?! What app did this?
Never, because I am not stupid enough to run untrusted software on an OS that provides no protection against it. The thing you fail to understand is that not being able to run untrusted applications is already the problem.
Also ever looked around in the computing world? Viruses, malware and all that stuff is causing plenty of problems.
And to repeat myself, as you happen to ignore that:
"I mean seriously, take whatever arguments you have for user privilege separation, do s/user/application/ and be done with it. It's the same thing really."
In the real world that isn't a problem, you keep saying it's a problem yet it's a problem no-one has
When an app deletes all your files, that's a problem. When an application looks around all your files, that's a problem (plenty games do that). When your OS offers you nothing to prevent that, that's a problem. When you have to use a slow ugly sandbox such as Flash because your OS doesn't offer that functionality, that's a problem as well.
I mean seriously, take whatever arguments you have for user privilege separation, do s/user/application/ and be done with it. It's the same thing really.
but yet again you fail to give specifics on the problem,
The problem is that you have to blindly trust your application and can't run an untrusted one. And if you don't consider that a problem, then well, I can't help you.
Wrong, they are popular because that control is not something the user has to deal with because they simply do not want to. Your idea gives no benefit, just more work for the user when they want to do things.
In case you missed the point:
* web applications don't have to be installed * web applications have no access to the users system unless the user explicitly uploads a file
Sounds kind of like exactly what I described. The only real difference is that my approach would run on a desktop computer in a chroot-like thing instead of a Google cloud server.
You seem to be having a great deal of difficulty that no-one else is having with applications accessing files, where is this specifically an issue for you?
Your mindset seems to be stuck in the Windows95 world where privilege separation is evil and everything needs to have access to everything.
You open a file dialog and click on stuff. With the file dialog however being a part of the OS, instead of the application, thus having the ability to transfer privileges. To put it in Unix terms (just very rough example, use your imagination for the rest):
sudo cat/etc/passwd | sed | sudo tee/etc/passwd
The sed process there never needs direct access to anything other then stdin and stdout, yet, even with those strict limitations it can edit any file on the HDD, thanks to the OS/user given it exactly what it needs to do the work and not more.
The "sudo cat/etc/passwd" in here would be the file load dialog, and the "sudo tee/etc/passwd" the file save dialog, with the "sed" being the application.
Of course in more complex cases "sed" wouldn't be completely isolated, but run in a chroot of some kind and instead of just passing the data once, you could link it into the chroot to make it permanently available to the app or collect it in a folder/bundle and then export multiple into the chroot at once.
Essentially, if at any point you create a reference to a file, you can use that action to give permission to access the file to the application.
How does it know that the new application you've just installed is the same application as the old one?
Cryptographic signatures and package management systems.
Newsflash, no-one needs such a system that would be cumbersome, slow and eat up masses of memory.
Welcome to the future, we have Gigabytes of memory and Terabytes of storage, wouldn't hurt to waste a bit of that to make computer systems far more maintainable and better to understand. Hardware is a hell of a lot cheaper then humans and we waste a shit load of time these days with maintaining computers. I personally would prefer to keep control at the users hand and not move it all into the cloud, which at this point, seems to be the only thing to keep things maintainable on a large scale.
Your lack of understanding of computing fundamentals just shows how flawed your 'concept' is,
It's not flawed, it's pretty much how the whole web works and why WebApps are so damn popular.
Slashdot Mirror
Yep, even more importantly, the OPs problems are a very general ones with the way the Internet and the whole cloud thing works these days. There are a ton of cloud services that let you enter data in, but there are only a very tiny few that actually let you get the data back out of the cloud again. It's a problem that isn't just limited evil cooperations, many open source project hosters for example suffer from this as well and provide only partial data export, which becomes a major annoyance when you want to move data from one host to another. Essentially proper data import and export is at best an afterthought, if offered at all, while it really should be a standard feature from every service handling data.
The biggest problem with complaining about GUI is that none of the problems are really GUI specific, they are specific to bad GUI implementations. Searching for files for example has been getting worse and worse with every Windows version, back in Windows95 days on the other side it was great:
1) Hit F3 to launch the search dialog (no need to specify directory, as that comes from the folder you are currently in)
2) Type search pattern (limit by date, filesize, filecontent if you like)
3) Start search
4) Observe the results and do something with them (delete, copy, etc.)
It was faster and more comfortable then 'find' as it gave you visual confirmation of what it was doing and gave you the option to subselect and sort the result. Shell is only easy when everything fits into computer readable patterns, if you ever wanna delete some photos and want to have a visual thumbnail confirmation that those are the right ones, classic shell isn't all to much helpful.Equally it is all that helpful if you only want to toy around with some files in the results, not all of them. And that shell only gives you text, not data, also leads to a lot of problems (i.e. half the shell scripts you find will explode when somebody put a newline in filename), a GUI doesn't have those problems, of course a more modern shell won't either, but those aren't exactly part of the classic Unix toolbox.
The tragic part of this whole depate is that it is really missing the point, Shell and GUIs are not opposites, they are both part of the same interface and there is absolutely no reason (aside from messy historic ones) why they shouldn't be able to work together. "ls" for example should give me a list of files that I can click and move around like everything my file browser would show and equally whenever there is a textbox or listbox in my GUI I should be able to grep and awk on it. Yet no modern GUI really tries to bother with that stuff, they are all stuck in the mindset that command line is evil and not worth bothering with. While command line people get all agressive when somebody mentioned that the world has evolved in the last 30 years and serial terminals are no longer state of the art.
That's actually a large part of the benefit of native applications.
That would only be a real benefit when the available native widgets would be more advanced, but they are not, they stopped developing new stuff 20 years ago, thus you are stuck with list boxes, menus and a few buttons. Take an email or usenet client for example, most follow the three pane view, threads on top, group view on left and a message view on the bottom. Sounds nice in theory, in practice that interface however is pretty bad and the way webpages like Slashdot or Gmail present threaded discussions, with all the posts fully visible in the tree itself is far more readable and requires far less clicks then having tree and messages separated into different panes. Native GUIs also have a lot of issues with basic things such as selecting text, which is almost always limited to a single widget, tough luck if you want to select subject and body of an email and the subject happens to be in a separate widget. Even worse, a lot of text in non-user editable fields is often not selectable at all.
Consistency is of course a nice goal to have, but with current day native GUI widget it just means that you are incredible restricted in what you can do with the app and how you can present information. There is of course the easy way around that in native apps by using custom widgets, but then you lose all consistency and are back to what webpages do.
Now don't get me wrong, the way webpages do GUI isn't pretty either, far from it, but native GUI widget really aren't the solution, not even close.
A large part of the problem with "running applications natively" is that the native programming interfaces aren't really build to handle the kind of applications that run on the web. How would Wikipedia look as a native Gtk+ app? How would Facebook? It's kind of hard to imagine that type of applications stuffed into a classic GUI toolkit. Of course it could be done, but you would probably end up doing it by embedding a HTML widget and then you are basically back at square one.
That of course doesn't mean that there aren't some web apps that would work much better natively, but overall the native GUI interfaces haven't really evolved much in the last few decades and the freedom that HTML gives has allowed a lot of applications that would have never evolved in a normal GUI landscape constrained with menus, toolbars, listboxes and other basic widgets.
How sure are we that the speed of light in vacuum is really the maximum speed of light? One random idea that comes to mind: What we consider vacuum might not be as empty as we think, it might be filled with some kind of dark matter. Light traveling through matter is slower then light in a vacuum. Thus light traveling through our not-quite-vacuum is slower then the actual speed limit of the universe. Neutrinos might not interact with dark matter and thus get a little closer to whatever is the absolute speed limited is. The problem would thus not be that C is wrong, but just that it's a little bigger then assumed.
Of course that's just a crackpot idea, I have no idea what I am talking about.
All the problems arise from the use of human beings in the design, implementation, and maintenance processes.
The problems aren't humans, but the systems in which they have to work. Just like any mechanical or computer competent, humans tend to fail from time to time and just like with any other failure you can prevent that from causing catastrophic failure by building redundancy and checks into the system. Those redundancies and checks of cause have to be forced by regulation, as nobody is building them in when they can save a bit of money leaving them out.
If the banks would really care about those things they could install video surveillance. Take a reference picture of the machine, compare it with how the machine currently looks, if objects are out of place, give alarm and lock the machine down.
The problem with all the monopoly regulation is that it only triggers when you already have a monopoly, it doesn't nothing to prevent one from forming. Thus Google might get into trouble for things that all their competition are doing as well, because they (almost) have a monopoly in search.
Rasterizing is O(N) in nr of triangles.
Ray tracing is better than O(logN), approaching O(1) even.
That's only really true for theoretical best-case scenario for raytracing and worst case for rasterization. In practice things look very different, as any real world realtime rasterisation engine will do LODs, tessellation, octrees, occlusion queries and whatever to drastically cut down the triangle count they have to render in rasterization, make it no longer O(N), but something much smaller. Equally O(logN) is only true for static scenes, when you have dynamic ones things look quite different as you and you have to include the cost of building your space partitioning into the whole thing.
And in the end, raytracing or rasterization is really not issue, the interesting thing is how you space partition your scene, as that will have a far bigger impact.
There is also this bit:
And not so long ago there has been a similar study into the Brain Age games, which basically showed that playing Brain Age makes you better at playing Brain Age, but doesn't really transfer into other areas.
It's free advertisement, you wouldn't have this Slashdot article when it wouldn't be for recycling an old games name and you wouldn't have many other gaming news articles either.
Speaking about radio waves, I always have a hard time visualizing how they fly through the air, what shields them, what reflects them, what is transparent for them, etc. So does anybody know images that demonstrate how the world would look like when seen with radio waves instead of regular light, how a room would look like just illuminated by your WLan router? For IR one can find a few nice pictures such as these, but for radio waves I haven't been able to find anything, aside of course from astronomy pictures, but I am looking more for everyday life.
PS: I know there are issues with resolution that would make a regular "photo" impossible, but putting in some equations into a raytracer might be doable.
to simulate motion blur, but I don't know if any do.
Pretty much all modern games use motion blur. Some of course use it better then others and it is often not quite as high quality as one might want it to be, but motion blur itself is almost everywhere these days (most noticeable when swinging the camera around in a third person shooter).
The Wiimote is an absolute pointing system, not a relative one. It is just a very bad absolute pointing system as it only has two dots for reference, not the three or four that it would need, and thus gets mis-calibrated the moment you move its position. Of course it also doesn't even allow real calibration to begin with, aside from the "Sensorbar above/below TV" setting (some games go a little further).
Interestingly however the Wiimote actually can actually detect four dots, it's just that the sensorbar only provides two, so homebrew software and another sensorbar should give you proper aiming.
The power glove used ultrasonic transmitter, triangulation and the time it took the sound to reach the mic, the Wiimote works with LED lights and a camera. So it's not really the same. A much closer match are however lightguns, they have been around for ages and the later models, that worked with LCD TVs also used LED markers.
LOL. Just from curiosity, since I'm seeing you a tad worried, what is your rate "page-flicks per seconds"?
When it comes to reference books, something like a 100 page flips per second isn't that unusal to find the thing you are looking for. Even a fast ebook display is no better then something like 2 or 3 page flips a second, which is perfectly fine for reading a book, but way to slow for browsing a book. Even your average PDF reader on a PC has a hard time coming near to a real books performance, let alone the tactile feel of it (pages you already read are easier to find again, then pages you haven't touched, thickness gives indication where you are in the book, etc.).
eBooks have a lot of advantages, I love that the page is always flat, not warped, that it stays open without any extra effort, that you can carry around hundred of books, etc., but the tactile browsing that paper books allows has yet to be matched by any electronic reading device. It's however not an unsolvable problem, intelligent bookmarking, keeping track of which pages have been read, zoomable-interfaces or simply analog buttons for moving forward and backwards through the book could go a long way in either matching or surpassing the experience of a real book.
Applications don't have full access to the user's system now, do the concepts of UAC and sudo completely elude you?
Under those the amount of access that an application has to the system is still far to huge (i.e. everything the user has access to, only root/admin are forbidden).
I'm not anti-sandboxing because in some places it makes sense - like in the case of JS and Flash
So how exactly is running a random game as .exe any different then running it as Flash or Javascript? The implementation differs, the purpose of the application and in turn what it should and shouldn't be able to do to the users system is exactly the same.
So by your logic it would be totally ok if every Javascript and Flash app had full access to the users system because running untrusted application isn't a problem?
I would be hopping mad if my (paid for) business webmail provider suddenly decided to do some rifling through my email for their own purposes, as that is not what I agreed to.
It's not quite that simple. If you use your paid for business webmail account without privacy invasion and then mail a GMail user, then Google suddenly has a mail from you that it can sniffle through. If you happen to mail a lot of Google Mail users, they might end up with quite a few of your emails and a decent personality profile even so you never had a Google account.
The problem with privacy invasion in communication is that your privacy can leak at both ends and you generally only have control over one.
And this wouldn't prevent that because already users will grant an application whatever privileges it asks for.
Viruses and malware spreads exactly because on todays OSs there is no asking for privileges, apps just do whatever they want without the user ever having a chance to intervene or know what is going on. But hey, you don't consider that a problem and totally ok. Fine with me, it looks like I can't argue you out of your Win95 mindset.
And when has this ever happened to you?! What app did this?
Never, because I am not stupid enough to run untrusted software on an OS that provides no protection against it. The thing you fail to understand is that not being able to run untrusted applications is already the problem.
Also ever looked around in the computing world? Viruses, malware and all that stuff is causing plenty of problems.
And to repeat myself, as you happen to ignore that:
"I mean seriously, take whatever arguments you have for user privilege separation, do s/user/application/ and be done with it. It's the same thing really."
In the real world that isn't a problem, you keep saying it's a problem yet it's a problem no-one has
When an app deletes all your files, that's a problem. When an application looks around all your files, that's a problem (plenty games do that). When your OS offers you nothing to prevent that, that's a problem. When you have to use a slow ugly sandbox such as Flash because your OS doesn't offer that functionality, that's a problem as well.
I mean seriously, take whatever arguments you have for user privilege separation, do s/user/application/ and be done with it. It's the same thing really.
but yet again you fail to give specifics on the problem,
The problem is that you have to blindly trust your application and can't run an untrusted one. And if you don't consider that a problem, then well, I can't help you.
Wrong, they are popular because that control is not something the user has to deal with because they simply do not want to. Your idea gives no benefit, just more work for the user when they want to do things.
In case you missed the point:
* web applications don't have to be installed
* web applications have no access to the users system unless the user explicitly uploads a file
Sounds kind of like exactly what I described. The only real difference is that my approach would run on a desktop computer in a chroot-like thing instead of a Google cloud server.
You seem to be having a great deal of difficulty that no-one else is having with applications accessing files, where is this specifically an issue for you?
Your mindset seems to be stuck in the Windows95 world where privilege separation is evil and everything needs to have access to everything.
And this is done how?
You open a file dialog and click on stuff. With the file dialog however being a part of the OS, instead of the application, thus having the ability to transfer privileges. To put it in Unix terms (just very rough example, use your imagination for the rest):
sudo cat /etc/passwd | sed | sudo tee /etc/passwd
The sed process there never needs direct access to anything other then stdin and stdout, yet, even with those strict limitations it can edit any file on the HDD, thanks to the OS/user given it exactly what it needs to do the work and not more.
The "sudo cat /etc/passwd" in here would be the file load dialog, and the "sudo tee /etc/passwd" the file save dialog, with the "sed" being the application.
Of course in more complex cases "sed" wouldn't be completely isolated, but run in a chroot of some kind and instead of just passing the data once, you could link it into the chroot to make it permanently available to the app or collect it in a folder/bundle and then export multiple into the chroot at once.
Essentially, if at any point you create a reference to a file, you can use that action to give permission to access the file to the application.
How does it know that the new application you've just installed is the same application as the old one?
Cryptographic signatures and package management systems.
Newsflash, no-one needs such a system that would be cumbersome, slow and eat up masses of memory.
Welcome to the future, we have Gigabytes of memory and Terabytes of storage, wouldn't hurt to waste a bit of that to make computer systems far more maintainable and better to understand. Hardware is a hell of a lot cheaper then humans and we waste a shit load of time these days with maintaining computers. I personally would prefer to keep control at the users hand and not move it all into the cloud, which at this point, seems to be the only thing to keep things maintainable on a large scale.
Your lack of understanding of computing fundamentals just shows how flawed your 'concept' is,
It's not flawed, it's pretty much how the whole web works and why WebApps are so damn popular.