carbonize wrote:And how would they do that unless they added themselves to a list somewhere?
Please do not make technical arguments, when do lack basic understanding about said technology. FYI, a basic concept in programming, when an object should interact with another one, is that there are a few possibilities how to do it: A can "call" B. B can "poll" A. A can leave a note in B's memory, and B then polls that memory. A can leave a note in its own memory, and then B polls that memory.
Even then being a portable app would mean it wasn't integrated in to your Windows thereby reducing the protection it would offer.
This is so screwed logic that i cannot even bother to reply. Hmm, i just have a deja vu - weren't you the same person that replied to my security model thread, with questions that showed that he did not understand what i was talking about? I see a pattern repeat here.
lyx wrote:
.NET wouldn't be such a big beast and instead be designed to be integrated into the application distribution (only the parts necessary for that app).
Resulting in bloated apps because instead of just having the gui components once on your system each app would have to come with them.
Once again, you do not know what you're talking about. The above is a myth. It's a calculation that sounds nice in theory and on some programmers OSes, but which in practice DOESNT ADD UP BY A MILE. In practice, the "savings" of this approach are usually eaten up by:
1) The buerocracy of said dinosaur (its own infrastructure gets bloated) because of so much glue-code and "managing management"
2) Version hell. Sooner or later, backwards compatibility needs to broken, but the apps installed on a machine will depend on different versions, so that the one-time-initial-cost actually multiplies, since you need to have the framework installed multiple times (one per major version).
3) The fact that most people do not have enough applications installed running on such a framework, to compensate the initiall cost. It only adds up when a VERY high percentage of applications use it. Framework developers like to imagine, that they are the only framework on the planet, and that everyone will love it so much, that everyone will write for that framework. In 98% of cases, that doesn't happen. It doesn't even happen for perhaps the most commonly used framework of all: DirectX in the end requires MORE memory, because of #2 - version hell.
Once again, here techfreaks argue against portability, in an i'll directed sense of conserving memory. Memory saving matters, but you're doing it wrong, sir! To do it "right", you cut costs where there are practical savings (not just imaginary theoretical ones), and you cut costs where the resulting disadvantages are minor.
Yes, i know, i basically just said that the linux architecture (regarding dependency hell) was made by morons. I fully stand by that. Linux made a few very interesting and nice choices in its evolution, but it also mostly was developed by, what in germany we call "Fachidioten". People who are the best at coming up with theories, and the worst at understanding practice.
lyx wrote:Another benefit is roaming. If all apps would reside in the users profile, then there is little left to do, to have entire portable user profiles, without the need for any magic.
This is why browsers now come with server side syncing same with certain messenger programs. If we used portable apps on our computers then we would have to copy the folder to our USB stick every time you left the PC just in case you ended up using a PC somewhere else.
Again, you advocate the status quo, for the sake of keeping life miserable for everyone.
Your offer:
1) Sync everything manually by copying
2) Install one vendor-controlled sync-app for EVERY F*CKING APPLICATION IN YOUR PROFILE - and then let them do it automagically on start
I offer:
- F*ck this inefficient insanity. How about you just put a SINGLE filesynchronizing application on your usb-drive, immediatelly accessable upon launching it's desktop, and able to sync with just 2 mouseclicks?