-3

GNOME(nautilus) checks on some external medium of presence autorun.inf files. We should do this in some more Unix way and check of presence ./install.sh and ./autorum.sh files.

I recal KDE3 have option to automatically run ./autorun.sh file, when external medium was inserted. Maybe should you reimplement this option?

Wouldn't this be considered dangerous behavior? Even MS disabled this in Windows

I don't ask for automatically run installers from external medium, but add possibility(for button in file manager or button in device notifer).

Sorry - my bad.
"I recal KDE3 have option to automatically run ./autorun.sh file, when external medium was inserted. Maybe should you reimplement this option?"

I have in mind to show top bar with possibility to run installer or to show button to run installer in device notifier.

Such a feature encourages companies and other providers of hard and software to write and enforce their own "installer" approach to deliver software instead of supporting the existing software management systems. There are many reasons against the use of such proprietary installers: in the end their usage boils down to two aspects:

• You perform a "wild" installation. So you copy files into your system without any means to track them, to control and upgrade, preventing damage to your system and detect and solve collisions.
• You typically have to hand over administrative control over your system to someone else you don't really have any information about in the end. You are expected to have ultimate trust into such installers without any evidence why you should.

Open source systems have a tradition of using another approach: software repositories and a unified package format and installation system. That approach has proven to result in different behavior of both, suppliers and consumers when comparing it to "other" environments or markets. Users stay in much better control over their systems and gain a better awareness of security and separation. Do we really want to open our systems again and drop all that just to reach that state again where hardware distributors force you to roam the internet for the latest drivers, having to test install them without any way of deciding if that file actually is malware or legitimate? Again inviting those producers too lazy to provide transparent and format conform packages to just drop some **** "installer" at your system and doing whatever harm they do not care about to your system? I think that finally, after decades of hard fighting nearly all important hardware producers comply with the approach and contribute their code and knowledge. Let's not ruin that development!

Yes - better way is support Listaller, but Listaller isn't development. You must also be aware that /install.sh is used by many applications currently, so KDE must support older application.

And of course - if there's one standard dependency description/package standard, we must add possibility to automatically run package installer , when CD is inserted.

Lachu wrote:Yes - better way is support Listaller, but Listaller isn't development. You must also be aware that /install.sh is used by many applications currently, so KDE must support older application.

And of course - if there's one standard dependency description/package standard, we must add possibility to automatically run package installer , when CD is inserted.

Sorry, I have no idea what "Listaller" is... I just fail to make any sense of that mentioning.

In a way you are right, that some software uses some ./install.sh" file during its installation process. But you should separate that from the question of how the install process is initiated. The second has little to do with the first. Such an install script may be be used whilst installing a package via the package management of your system. But it is started by the process launched in the protected environment of the software management and typically has been retrieved by safe means, so by loading it from a signed and monitored software repository users can trust. All that is (usually) not given when you install from some removable medium.

You are certainly right that there are software packages that are not installable via the software management system. But I completely disagree that "KDE must support" such packages. Why? First you yourself say they are old, then, why not create a clean package and load it via the more secure channels instead of bypassing the software management system? And if it really is not possible to create a clean package then the only reason I can imagine is that it is some proprietary software where the licensing terms prevent that. No one keeps you from installing such software on your system. But I disagree that such actions should be actively supported, thus pushed.

It again boils down to the massive security thread such action is. Which interesting enough is some aspect you did not even reflect...
I wonder why, is it because security has a much lower priority to you that a minimal raise of convenience?

Current Listaller name is Limba. Limba will install packages into sandbox, similar to xdg-apps, so supporting installing Limba or xdg-apps packages from external medium are better than running install.sh script.

In my opinion KDE Dev team could allow to run install.sh script by displaying warning and ask user to accept execution. You can achieve this by special FUSE filesystem, which will be some kind of union(layered) fs, but instead storing files changes, it will store attributes changes. KDE is simple and powerful. It should disallow users to doing any task, but warning instead disallowing.