Pandora's Gui? Will It Even Have One?

[WizardStan]

...so the user would manually have to write them? Or download them separately from somewhere? Huh?

You were just talking about using a package manager to install applications, and updating files in /etc and creating symlinks for data files, but editing a text file at the root of the SD card makes you hesitate?
I think you're looking for a harder solution than you need. The suggestion is that you've got all your PND files on an SD card, and on that card you have some sort of rd/autorun/other file which tells the kernel how to start certain of the PND files at boot or on insert, just as the rc files do. The file could be manually or automatically updated, just as it is with a package system. First time you insert your SD card, you run the Apache app. It scans your SD.rd file, sees that it hasn't been installed, and updates it itself. The kernel will then check this file at every startup and do it's stuff. Obviously no such thing exists yet, but it doesn't seem impossible to implement, as a later revision.
Final point is that I don't think the situation is nearly as bad as you make it out to be. There are simple* solutions to all the problems that you've mentioned.

*for a definition of "simple" that somehow means not having to break your back (or code) to achieve it.

 

[God Ginrai]

...so the user would manually have to write them? Or download them separately from somewhere? Huh?

You were just talking about using a package manager to install applications, and updating files in /etc and creating symlinks for data files, but editing a text file at the root of the SD card makes you hesitate?
I think you're looking for a harder solution than you need. The suggestion is that you've got all your PND files on an SD card, and on that card you have some sort of rd/autorun/other file which tells the kernel how to start certain of the PND files at boot or on insert, just as the rc files do. The file could be manually or automatically updated, just as it is with a package system. First time you insert your SD card, you run the Apache app. It scans your SD.rd file, sees that it hasn't been installed, and updates it itself. The kernel will then check this file at every startup and do it's stuff. Obviously no such thing exists yet, but it doesn't seem impossible to implement, as a later revision.
Final point is that I don't think the situation is nearly as bad as you make it out to be. There are simple* solutions to all the problems that you've mentioned.

*for a definition of "simple" that somehow means not having to break your back (or code) to achieve it.

This is more or less what I meant. However, there might be more than one of the .*rc files to further group startup data, and you mihgt put them in folders to further organize them. (Like a startup folder or somesuch)

-God Ginrai

 

[dflemstr]

The file could be manually or automatically updated, just as it is with a package system.

Well, as I've said before, a PND may not modify the rest of the system for integration's sake. I'm not sure, but I think that the applications launched inside a PND will run in some kind of chrooted environment, or otherwise run with the user's privileges. Remember, the ONLY way to start an application inside of a PND is to either click on the generated .desktop file that the PND disco daemon creates for the PND, or manually start "/mnt/random_pnd_id839823618279/bin/application" from a terminal (and that path will be practically random each time the PND is mounted). So, without breaking the current format, something like this cannot happen.

You propose that the application should add .*rc files itself on first launch, but 1. the app will run with user privileges so no /etc/rc.d access, 2. you'd have to either make a wrapper script or similar, since neither you nor me want to edit the Apache source code, and 3. the files generated would still be there when the PND is unmounted, potentially causing problems. BTW, 4., what if the application cannot launch before having some set of files already present in the file system, 5. if those files take up more space than the NAND has available and 6. there are viri in the "population script" (that would have to run with root privileges due to problem 1.)?

EDIT: Yeah, if we're allowed to throw the whole PND system upside down, then this can happen, but there are still security implications, etc.

 

[WizardStan]

You propose that the application should add .*rc files itself on first launch, but 1. the app will run with user privileges so no /etc/rc.d access, 2. you'd have to either make a wrapper script or similar, since neither you nor me want to edit the Apache source code, and 3. the files generated would still be there when the PND is unmounted, potentially causing problems. BTW, 4., what if the application cannot launch before having some set of files already present in the file system, 5. if those files take up more space than the NAND has available and 6. there are viri in the "population script" (that would have to run with root privileges due to problem 1.)?

The rc files are created on the SD card, which the user should have write privileges to. That takes care of 1-5, and 6 is also a problem with package installation anyway: you have to trust your source.

 

[dflemstr]

You propose that the application should add .*rc files itself on first launch, but 1. the app will run with user privileges so no /etc/rc.d access, 2. you'd have to either make a wrapper script or similar, since neither you nor me want to edit the Apache source code, and 3. the files generated would still be there when the PND is unmounted, potentially causing problems. BTW, 4., what if the application cannot launch before having some set of files already present in the file system, 5. if those files take up more space than the NAND has available and 6. there are viri in the "population script" (that would have to run with root privileges due to problem 1.)?

The rc files are created on the SD card, which the user should have write privileges to. That takes care of 1-5, and 6 is also a problem with package installation anyway: you have to trust your source.

I don't see 2-4 solved yet

 

[God Ginrai]

You propose that the application should add .*rc files itself on first launch, but 1. the app will run with user privileges so no /etc/rc.d access, 2. you'd have to either make a wrapper script or similar, since neither you nor me want to edit the Apache source code, and 3. the files generated would still be there when the PND is unmounted, potentially causing problems. BTW, 4., what if the application cannot launch before having some set of files already present in the file system, 5. if those files take up more space than the NAND has available and 6. there are viri in the "population script" (that would have to run with root privileges due to problem 1.)?

The rc files are created on the SD card, which the user should have write privileges to. That takes care of 1-5, and 6 is also a problem with package installation anyway: you have to trust your source.

I was about to reply to his post and then I saw your post, which basically covered exactly what I was going to say.

-God Ginrai

 

[Kramy]

Not unlike autorun.inf.

My thoughts exactly.

I turn that POS off on all my windows boxes.

So... from the sounds of it, we have no issue. Giddy developers want autorun, so they can set up installers that automatically do stuff behind our backs.

I don't, and I'm hoping most other people here don't. If you want Apache running, edit your own rc files.

Well, as I've said before, a PND may not modify the rest of the system for integration's sake. I'm not sure, but I think that the applications launched inside a PND will run in some kind of chrooted environment, or otherwise run with the user's privileges. Remember, the ONLY way to start an application inside of a PND is to either click on the generated .desktop file that the PND disco daemon creates for the PND, or manually start "/mnt/random_pnd_id839823618279/bin/application" from a terminal (and that path will be practically random each time the PND is mounted). So, without breaking the current format, something like this cannot happen.

This reassures me about the design.

 

[dflemstr]

I think that Kramy has the correct POV here. I've been bickering around for too long. I am the kind of guy who likes systems with nice defaults that just *work* while still being nicely implemeneted (Hey, I'm on Arch Linux so that should tell you everything you need to know about me).

I'll stop bumping this thread now

 

[WizardStan]

1: doesn't need /etc privileges, as it's written to the SD card, which should hopefully have user write privileges.
2: ... point taken. A short startup script would need to be made that effectively "installed" stuff. This would need to be done anyway, to create a default (or user guided) httpd.conf file anyway, so might as well create the rc file too. And if you suggest "the user should be smart enough to manually create their own httpd.conf file" I'm going to reverse that and say the user can similarly create the rc file then.
3: It's on the SD card. It goes with the application it's intended to start, which is conveniently also on the SD card.
4: It's on the SD card. It can't launch until after it's mounted.
5: It's on the SD card. No space needed on the NAND, except for the extra code needed to look for and start these rc files.
6a: Trust is always an issue. Whether it's an ipkg install or a PND file downloaded off the official repository.
6b: The rc on the card doesn't need to be started with root privileges. It can execute exactly as if the user had run everything.

 

[God Ginrai]

Not unlike autorun.inf.

My thoughts exactly.

I turn that POS off on all my windows boxes.

So... from the sounds of it, we have no issue. Giddy developers want autorun, so they can set up installers that automatically do stuff behind our backs.

I don't, and I'm hoping most other people here don't. If you want Apache running, edit your own rc files.

Well, as I've said before, a PND may not modify the rest of the system for integration's sake. I'm not sure, but I think that the applications launched inside a PND will run in some kind of chrooted environment, or otherwise run with the user's privileges. Remember, the ONLY way to start an application inside of a PND is to either click on the generated .desktop file that the PND disco daemon creates for the PND, or manually start "/mnt/random_pnd_id839823618279/bin/application" from a terminal (and that path will be practically random each time the PND is mounted). So, without breaking the current format, something like this cannot happen.

This reassures me about the design.

Autorun.inf was an example of something similar, not exactly the same. Also, all the autoruns on Windoze systems are normally bad and invasive. You are a god damn idiot if you think that the developers shouldn't ever have their way, because they are the foundations of this project. The Pandora is nothing without people to develop applications for other users to use. Get off your damn high horse and realize that the devs deserve their way more than you will ever deserve yours.

I am the kind of guy who likes systems with nice defaults that just *work* while still being nicely implemeneted (Hey, I'm on Arch Linux so that should tell you everything you need to know about me).

It still can be nicely implemented, it's just a different implementation than what you are used to. There is never only one way to implement something.

1: doesn't need /etc privileges, as it's written to the SD card, which should hopefully have user write privileges.
2: ... point taken. A short startup script would need to be made that effectively "installed" stuff. This would need to be done anyway, to create a default (or user guided) httpd.conf file anyway, so might as well create the rc file too. And if you suggest "the user should be smart enough to manually create their own httpd.conf file" I'm going to reverse that and say the user can similarly create the rc file then.
3: It's on the SD card. It goes with the application it's intended to start, which is conveniently also on the SD card.
4: It's on the SD card. It can't launch until after it's mounted.
5: It's on the SD card. No space needed on the NAND, except for the extra code needed to look for and start these rc files.
6a: Trust is always an issue. Whether it's an ipkg install or a PND file downloaded off the official repository.
6b: The rc on the card doesn't need to be started with root privileges. It can execute exactly as if the user had run everything.

+1

-God Ginrai

 

[dflemstr]

1: doesn't need /etc privileges, as it's written to the SD card, which should hopefully have user write privileges.
2: ... point taken. A short startup script would need to be made that effectively "installed" stuff. This would need to be done anyway, to create a default (or user guided) httpd.conf file anyway, so might as well create the rc file too. And if you suggest "the user should be smart enough to manually create their own httpd.conf file" I'm going to reverse that and say the user can similarly create the rc file then.
3: It's on the SD card. It goes with the application it's intended to start, which is conveniently also on the SD card.
4: It's on the SD card. It can't launch until after it's mounted.
5: It's on the SD card. No space needed on the NAND, except for the extra code needed to look for and start these rc files.
6a: Trust is always an issue. Whether it's an ipkg install or a PND file downloaded off the official repository.
6b: The rc on the card doesn't need to be started with root privileges. It can execute exactly as if the user had run everything.

I fear that you've misinterpreted some of my points. When I mean that a PND file is moutned, I really mean *mounted*. Since a PND basically is an ISO file, it's mounted before it's started (and only then, otherwise it resides unmounted on an SD card somewhere).

Also, you would actually need to extract files on the NAND, since that's where the /etc/rc.d folder is.

So, a PND file is mounted, extracts it's files to a SD card, and is then unmounted (and for various reasons, there just can't be "unmount scripts" that are executed). The init process (for example) of the system then receives a "telinit 6" (or something) and then tries to use the rc that an Apache PND has extracted. Everything blows up.

Or yeah, it could of course work if we created some kind of custom rc system that essentially would be an execution daemon and maintain some kind of UnionFS of the NAND and SD card to populate the correct folders, but good luck creating all of the wires. (What if I want to package an icon theme in a PND? How does /usr/share/icons get populated? etc etc)

The only sustainable solution I've been able to come up with is my symlink system, but even that isn't foolproof.

 

[God Ginrai]

1: doesn't need /etc privileges, as it's written to the SD card, which should hopefully have user write privileges.
2: ... point taken. A short startup script would need to be made that effectively "installed" stuff. This would need to be done anyway, to create a default (or user guided) httpd.conf file anyway, so might as well create the rc file too. And if you suggest "the user should be smart enough to manually create their own httpd.conf file" I'm going to reverse that and say the user can similarly create the rc file then.
3: It's on the SD card. It goes with the application it's intended to start, which is conveniently also on the SD card.
4: It's on the SD card. It can't launch until after it's mounted.
5: It's on the SD card. No space needed on the NAND, except for the extra code needed to look for and start these rc files.
6a: Trust is always an issue. Whether it's an ipkg install or a PND file downloaded off the official repository.
6b: The rc on the card doesn't need to be started with root privileges. It can execute exactly as if the user had run everything.

I fear that you've misinterpreted some of my points. When I mean that a PND file is moutned, I really mean *mounted*. Since a PND basically is an ISO file, it's mounted before it's started (and only then, otherwise it resides unmounted on an SD card somewhere).

Also, you would actually need to extract files on the NAND, since that's where the /etc/rc.d folder is.

So, a PND file is mounted, extracts it's files to a SD card, and is then unmounted (and for various reasons, there just can't be "unmount scripts" that are executed). The init process (for example) of the system then receives a "telinit 6" (or something) and then tries to use the rc that an Apache PND has extracted. Everything blows up.

Or yeah, it could of course work if we created some kind of custom rc system that essentially would be an execution daemon and maintain some kind of UnionFS of the NAND and SD card to populate the correct folders, but good luck creating all of the wires. (What if I want to package an icon theme in a PND? How does /usr/share/icons get populated? etc etc)

The only sustainable solution I've been able to come up with is my symlink system, but even that isn't foolproof.

Once again, you're misunderstanding. The .*rc file will never be extracted from a PND. It lives on the SD card, not zipped, tarred, etc. Second, you wouldn't need to edit /etc/rc.d, because the system would search the SD card for .*rc files that would be used along with /etc/rc.d

-God Ginrai

 

[dflemstr]

Once again, you're misunderstanding. The .*rc file will never be extracted from a PND. It lives on the SD card, not zipped, tarred, etc. Second, you wouldn't need to edit /etc/rc.d, because the system would search the SD card for .*rc files that would be used along with /etc/rc.d

OK, there's something major I'm missing here. As I see it, these issues still aren't resolved:

• How do the .*rc files come into existence? It has to happen without anything ever being executed inside of a PND ideally, or are you still saying that there should be an install script run on every PND mount?
• How do PNDs populate directories if they don't just offer daemons, but also icon themes (/usr/share/icons) or, say, KDE service files or plasmoids that need to be in the correct folders? (bad example, I know, but you get my point)

Maybe this discussion is futile by now... we don't seem to get anywhere.

 

[God Ginrai]

Once again, you're misunderstanding. The .*rc file will never be extracted from a PND. It lives on the SD card, not zipped, tarred, etc. Second, you wouldn't need to edit /etc/rc.d, because the system would search the SD card for .*rc files that would be used along with /etc/rc.d

OK, there's something major I'm missing here. As I see it, these issues still aren't resolved:

• How do the .*rc files come into existence? It has to happen without anything ever being executed inside of a PND ideally, or are you still saying that there should be an install script run on every PND mount?
• How do PNDs populate directories if they don't just offer daemons, but also icon themes (/usr/share/icons) or, say, KDE service files or plasmoids that need to be in the correct folders? (bad example, I know, but you get my point)

Maybe this discussion is futile by now... we don't seem to get anywhere.

I don't think I understand the second question in your list, but the answer to the first question is that when you choose an option either in the program on the PND, or on your OS that would warrant the need for such a .*rc file, the program would create the .*rc on the SD card. There shouldn't be any read-write issues because it is on the SD card.

-God Ginrai

 

[Kramy]

Autorun.inf was an example of something similar, not exactly the same. Also, all the autoruns on Windoze systems are normally bad and invasive. You are a god damn idiot if you think that the developers shouldn't ever have their way, because they are the foundations of this project. The Pandora is nothing without people to develop applications for other users to use. Get off your damn high horse and realize that the devs deserve their way more than you will ever deserve yours.

Sounds like you're the one on the horse. Or at least that's the impression I get from all this bantering with dflemstr.

Developers are used to restrictions. This seems like a rather logical restriction to me. It makes sense security wise, and it's the closest option to respecting what the user wants.

If you want an auto-install script, then make an auto-install script(install-apache, #!/bin/bash) and run it as root.

Anything that auto-installs from a PND (or on-detection on the SD card) is going to piss me off.

 

[dflemstr]

Once again, you're misunderstanding. The .*rc file will never be extracted from a PND. It lives on the SD card, not zipped, tarred, etc. Second, you wouldn't need to edit /etc/rc.d, because the system would search the SD card for .*rc files that would be used along with /etc/rc.d

OK, there's something major I'm missing here. As I see it, these issues still aren't resolved:

• How do the .*rc files come into existence? It has to happen without anything ever being executed inside of a PND ideally, or are you still saying that there should be an install script run on every PND mount?
• How do PNDs populate directories if they don't just offer daemons, but also icon themes (/usr/share/icons) or, say, KDE service files or plasmoids that need to be in the correct folders? (bad example, I know, but you get my point)

Maybe this discussion is futile by now... we don't seem to get anywhere.

I don't think I understand the second question in your list, but the answer to the first question is that when you choose an option either in the program on the PND, or on your OS that would warrant the need for such a .*rc file, the program would create the .*rc on the SD card. There shouldn't be any read-write issues because it is on the SD card.

I see. No way of doing that with Apache, but I guess noone will use that anyways

My second question is related to applications that are not launched. An extreme example would be a kernel driver: how would you "put" it in the kernel modules folder? Or should we modify the kernel too to scan all SD cards for modules?
Also, an icon theme (that typically is up to 50 MiB big) that soeone would want to put in a PND file: how would that be loaded by the system? All window managers look in the /usr/share/icon folder to find the correct icons, so how would you get the PND contents into that folder? You can't copy them to the folder because the NAND probably won't have space enough. You could of course have an application inside of the PND that would create a symlink from /usr/share/icons to the PND folder, but that symlink would be broken after a remount.

Yes, I know that I'm bickering about corner cases here and am trying to find problems, but that's why I said a while ago that this discussion was futile and should come to an end because so far, it hasn't led anywhere.

 

[God Ginrai]

Autorun.inf was an example of something similar, not exactly the same. Also, all the autoruns on Windoze systems are normally bad and invasive. You are a god damn idiot if you think that the developers shouldn't ever have their way, because they are the foundations of this project. The Pandora is nothing without people to develop applications for other users to use. Get off your damn high horse and realize that the devs deserve their way more than you will ever deserve yours.

Sounds like you're the one on the horse. Or at least that's the impression I get from all this bantering with dflemstr.

Developers are used to restrictions. This seems like a rather logical restriction to me. It makes sense security wise, and it's the closest option to respecting what the user wants.

If you want an auto-install script, then make an auto-install script(install-apache, #!/bin/bash) and run it as root.

Anything that auto-installs from a PND (or on-detection on the SD card) is going to piss me off.

I'm just realizing that without devs the Pandora is nothing. To give you an analogy: Without the baker there is no bread. If you get all fussy at the devs because everything is not the way YOU want it, then you will drive them away. I am on no such high horse, because I am not making any requests. I am not asking for this system I proposed to be implemented. I am merely suggesting it as a possible solution to dflemstr's problem.

Once again, you're misunderstanding. The .*rc file will never be extracted from a PND. It lives on the SD card, not zipped, tarred, etc. Second, you wouldn't need to edit /etc/rc.d, because the system would search the SD card for .*rc files that would be used along with /etc/rc.d

OK, there's something major I'm missing here. As I see it, these issues still aren't resolved:

• How do the .*rc files come into existence? It has to happen without anything ever being executed inside of a PND ideally, or are you still saying that there should be an install script run on every PND mount?
• How do PNDs populate directories if they don't just offer daemons, but also icon themes (/usr/share/icons) or, say, KDE service files or plasmoids that need to be in the correct folders? (bad example, I know, but you get my point)

Maybe this discussion is futile by now... we don't seem to get anywhere.

I don't think I understand the second question in your list, but the answer to the first question is that when you choose an option either in the program on the PND, or on your OS that would warrant the need for such a .*rc file, the program would create the .*rc on the SD card. There shouldn't be any read-write issues because it is on the SD card.

I see. No way of doing that with Apache, but I guess noone will use that anyways

My second question is related to applications that are not launched. An extreme example would be a kernel driver: how would you "put" it in the kernel modules folder? Or should we modify the kernel too to scan all SD cards for modules?
Also, an icon theme (that typically is up to 50 MiB big) that soeone would want to put in a PND file: how would that be loaded by the system? All window managers look in the /usr/share/icon folder to find the correct icons, so how would you get the PND contents into that folder? You can't copy them to the folder because the NAND probably won't have space enough. You could of course have an application inside of the PND that would create a symlink from /usr/share/icons to the PND folder, but that symlink would be broken after a remount.

Yes, I know that I'm bickering about corner cases here and am trying to find problems, but that's why I said a while ago that this discussion was futile and should come to an end because so far, it hasn't led anywhere.

You wouldn't actually be able to put them in the folder. But the .*rc files should be able to tell it where to put the symlinks once the SD is mounted, it could also tell it what to do incase an unmount happens.

-God Ginrai

 

[WizardStan]

Sounds like you're the one on the horse. Or at least that's the impression I get from all this bantering with dflemstr.

Banter helps solidify ideas. This idea may go nowhere, but so long as dflemstr keeps throwing objections and we continue to counter them, it's progress. Either we'll reach a point where we can go "hey, now this is a workable idea" or we hit a serious roadblock, which hasn't happened yet.

If you want an auto-install script, then make an auto-install script(install-apache, #!/bin/bash) and run it as root.

Anything that auto-installs from a PND (or on-detection on the SD card) is going to piss me off.

That is exactly the idea of the rc file that GG and I are proposing though. Download a Apache PND file (the example we've been using is Apache, so may as well continue), insert the card, and the icon appears on the desktop. You click the icon, and the executable inside the PND file first checks the SD card, notes that no autorun/rc/whatever-format-might-work-best file exists, and pops up a prompt "No RC file exists. Would you like to create one to automatically start Apache on boot up? <Y/N>"
And then it either continues to start in a one time mode (with the popup appearing again the next time you run it, or maybe it's a configurable option that only appears once, we'll deal with the details later) or creates the rc file so that the next time you shut down and restart or even insert your SD card, it automatically restarts Apache for you.
Or you can manually craft an rc file to start your PS1 emulator as soon as the card is inserted, because maybe you've got a 2 gig card with only PS1 games on it. Other examples exist. Point is that the rc files will still need to be created somehow, meaning user intervention: it doesn't happen unless you want it to.

My second question is related to applications that are not launched. An extreme example would be a kernel driver: how would you "put" it in the kernel modules folder? Or should we modify the kernel too to scan all SD cards for modules?

insmod <modulename>. module can be located anywhere. Put it in a PND file with a single executable script which checks if the rc file exists and, if not, creates it. Then it calls the insmod. Needs root access, so it pops up a window asking for your password. Only requirement would be to execute the PND file manually from the desktop the very first time it was loaded. After that, it's automatic. Or it doesn't have to be. Maybe you don't want to keep it on the SD card, in which case you should really copy it to the NAND and create an alias so it starts with the kernel.

Also, an icon theme (that typically is up to 50 MiB big) that soeone would want to put in a PND file: how would that be loaded by the system? All window managers look in the /usr/share/icon folder to find the correct icons, so how would you get the PND contents into that folder? You can't copy them to the folder because the NAND probably won't have space enough. You could of course have an application inside of the PND that would create a symlink from /usr/share/icons to the PND folder, but that symlink would be broken after a remount.

I'm sure we could figure something out, although honestly, this is completely outside the scope of what GG and I have been proposing. Changing the icon theme probably shouldn't be done with a PND file anyway. Extract the directory to the SD card, create (or maybe it is extracted from the archive) an rc file (see what I did there?) that symlinks it to /usr/share/icon, and voila.

 

[Kramy]

You click the icon, and the executable inside the PND file first checks the SD card, notes that no autorun/rc/whatever-format-might-work-best file exists, and pops up a prompt "No RC file exists. Would you like to create one to automatically start Apache on boot up? <Y/N>"

How very trusting of you. That's exactly what shouldn't be allowed.

I see a few viable options:
1) An "Installer" program downloaded from repository that can generate rc files for .pnd files.
2) A script to do the same thing. Perhaps distributed along-side .pnd files, for anyone that wants to install that specific app.

But this solution is bad, poorly thought out, and likely to be exploited by malware writers:
-Let the .pnd file decide if it wants to auto-start. Let it control whether there's even a popup.

I'm just realizing that without devs the Pandora is nothing. To give you an analogy: Without the baker there is no bread. If you get all fussy at the devs because everything is not the way YOU want it, then you will drive them away. I am on no such high horse, because I am not making any requests. I am not asking for this system I proposed to be implemented. I am merely suggesting it as a possible solution to dflemstr's problem.

You have the attitude of an annoying linux dev. "Users can suck it - only the developer matters! Now shove aside and let me auto-install my crap on YOUR [phone, PC]"

Well, that's fine, but please mark any software you release as "AUTOMATICALLY INSTALLS" so I can stay the hell away from it.

I agree that developers are important, but they (more than anyone else) should recognize when something may be prone to exploits, and isn't a necessary feature.

 

[WizardStan]

How very trusting of you. That's exactly what shouldn't be allowed.

Give me one good reason that isn't also a valid reason against package managers.

But this solution is bad, poorly thought out, and likely to be exploited by malware writers:
-Let the .pnd file decide if it wants to auto-start. Let it control whether there's even a popup.

If malware is getting into the official repository, you're already screwed.