Yo, that’s the question I’ve been thinking about. I don’t know all the technicalities so that’s why I wanted to write something about it.
Windows has portable exe files. Mac has dmg files which are mounted once and the application is dragged to the Applications folder. Linux has AppImage which is similar to these.
I believe both exe and AppImage could act like a Mac equivalent. Depending on how the application is configured it could set up a user profile when launched for the first time. I don’t think that counts as installation.
I’m not talking about applications such as WindowBlinds or Groupy which require deep system integration. I’m talking about ordinary applications.
I have been using LibreOffice with extensions and dictionaries as AppImage on Linux and that experience was the same as using an installed version, but without the system integration.
I believe Apple figured this out long ago and you get complete system integration by just dragging a file to the Applications folder.
It’s almost like I want to get a Mac just to use this “magic” myself.
Both Windows and Linux are good at spreading files all over the system and I’m thinking why not do it like macOS?
One file (archive) = one application. No need to pollute the system with files everywhere.
skane2600
<blockquote><em><a href="#296659">In reply to wright_is:</a></em></blockquote><p>Of course web apps have the same integration issues as portable apps, but at least the latter can be run without an Internet connection. Admittedly the lack of an Internet connection isn't that big of a problem these days, but "footprint" is even less of a problem. </p>
skane2600
<blockquote><em><a href="#296872">In reply to F4IL:</a></em></blockquote><p>The registry allows integration capabilities that AFAIK aren't supported by Linux in a standard way. I seriously doubt that most installers never delete registry entries. Deleting entries is no more of a danger to the state of the system than creating them.</p>
skane2600
<blockquote><em><a href="#296880">In reply to F4IL:</a></em></blockquote><p>The advantage of the registry is that it provides minimal coupling between programs. The code reading or modifying the other code's entries doesn't need to know any entry points or other internal details.</p><p><br></p><p>The idea that registry left-overs are the cause of performance degradation is more a matter of conjecture than proof and registry cleaner makers take advantage of some people's belief in this unproven theory.</p><p><br></p><p>It really shouldn't be that hard to test the theory. Take a new installation of Windows, measure performance and then write a lot of data to the registry and test again. That would isolate the effect of registry entries from other factors such as more background processes being added as more applications are installed.</p>
skane2600
<blockquote><em><a href="#296901">In reply to F4IL:</a></em></blockquote><p>What matters is the scale of the added time. Does a change of registry size result in a perceptible change in performance? Reinstalling Windows wouldn't prove the registry was the cause of the slow-down since the other factors would start at ground-zero too. </p>
skane2600
<blockquote><em><a href="#296924">In reply to F4IL:</a></em></blockquote><p>We don't know what "eventually" amounts to. Given that registry entries generally increase with added applications, disk space might be exhausted before significant performance is hampered by the registry. Not saying that's the case, but it might be.</p><p><br></p><p>I see you prefer the UNIX approach but your opinion isn't proof that the design used in UNIX represents more "thoughtful design and careful engineering" than that of Windows. This is a debate that has been going on for decades and there will never be a consensus on a conclusion. Both OS's have issues that relate to the era they were born in. </p>
skane2600
<blockquote><em><a href="#297199">In reply to F4IL:</a></em></blockquote><p>You're trying to equivocate between the fact that searching takes longer with more entries with the conclusion that the number of entries in the registry is the reason that Windows slows down significantly enough to be noticeable . Only the former is "outlined in university courses" but not the latter. </p><p><br></p><p>"The consensus is reached every time someone blows away and re-installs windows because he is experiencing the performance degradation. "</p><p><br></p><p>So you're just going to ignore other factors? Are universities now teaching that increasing the number of background processes don't consume more CPU time?</p><p><br></p><p>Perhaps some day someone will perform the experiment I proposed and we can replace our speculations with actual facts, but I guess I'm done arguing about this.</p>
skane2600
<blockquote><em><a href="#296917">In reply to hrlngrv:</a></em></blockquote><p>Yes, it does depend on definitions. I was referring to uses of the Registry that didn't involve calling another application's code. Do people actually use CORBA for local integration? Seems like heavy overkill to me.</p>
skane2600
<blockquote><em><a href="#296877">In reply to F4IL:</a></em></blockquote><p>I would say using multiple binaries is quite an old idea driven by the much more limited resources of the era they originated from. The idea was that binary code could be shared across multiple applications thus saving disk space and that dlls could be loaded and unloaded from memory as needed to save RAM. Limitations of storage and RAM have been greatly reduced since then so the case is a lot weaker than it once was. It's really just a form of optimization that almost always involves trade-offs.</p>
skane2600
<blockquote><em><a href="#296884">In reply to F4IL:</a></em></blockquote><p>This seems to be a rather cherry-picked scenario. But if the application exists as a single file, than a single file is all that needs to be updated just as in the dll case. Obviously the single file would probably be bigger, but it's still one file. The answer, of course, is the ever-less-popular practice of doing it right the first time. </p>
skane2600
<blockquote><em><a href="#296904">In reply to F4IL:</a></em></blockquote><p>I thought we were talking about installing applications, not about operating system design. Application programmers should be careful about including code that they haven't performed due diligence on. </p>
skane2600
<blockquote><em><a href="#296920">In reply to F4IL:</a></em></blockquote><p>Not all installation processes involve writing to the registry, but I wasn't claiming that the registry wasn't a MS design. I don't know if the SSL code you were referring to was a standard Windows implementation or that of a third party, but in any case, Windows is not an application nor is it implemented as a single file, so I don't really see it's relevance to this discussion. </p>
skane2600
<blockquote><em><a href="#297254">In reply to wright_is:</a></em></blockquote><p>"Squandering resources, "because we can" is not a good solution."</p><p><br></p><p>Not sure what you are referring to.</p>
skane2600
<blockquote><em><a href="#296569">In reply to longhorn:</a></em></blockquote><p>Kind of a strange thing for Jobs to say given how Apple's priority has almost always been form over functionality. </p>
skane2600
<p>Well, it depends on the application. I've seen Mac applications that require more than just dragging to the Applications folder and I've seen Windows applications that can be dragged wherever desired and run immediately. Obviously applications either have to copied from external storage or the Internet. Does a Mac application have to be dragged the the Applications folder to work or is it just a convention? I don't know.</p>