http://brainstorm.ubuntu.com/item/5744/
As a seasoned user of the terminal, the issue of an application having an icon embedded into it's executable is something that I didn't even notice until I started converting others to Ubuntu. Many users expect applications that they've downloaded to have recognizable icons, this icon is usually something familiar from visiting the website for the program. A good example of an application that's not already included in the Ubuntu repo is "songbird", which has a large egg right next to the download link and for its Windows icon.

(NOTE: Modified 03/27/08 to clarify and better explain impact)
(NOTE: Modified 01/18/09 to separate rationale and solution)

[41 votes] Solution #1: Embedding Icons in ELF Binaries


[1 votes] Solution #2: .deb files with (optional) custom icons


[-3 votes] Solution #3: both .deb and executables...


[0 votes] Solution #4: Add firefox handler for .run and .bin files!


]]> en-us Wed, 26 Mar 2008 04:18:45 +0000 Fri, 13 Nov 2009 19:20:33 +0000 QAPoll module http://brainstorm.ubuntu.com/idea/5744/ Wed, 26 Mar 2008 12:35:37 +0000 I agree, this is very needed!]]> Wed, 26 Mar 2008 14:51:10 +0000 This is definitely something we need.]]> Wed, 26 Mar 2008 14:57:12 +0000
You think Linux is OpenWindows?

Funny...]]> Wed, 26 Mar 2008 16:07:39 +0000 > I think we should encourage people to use proper repositories. Then the icons and stuff are included in the package manager.

The problem with that is that you cannot expect every software package to be distributed using the package manager. Myself I've run into lots of programs that I use daily that are not distributed: Quartus II, LabVIEW, Mathematica, LabVIEW, and Songbird are just a few.

Eldmannen wrote on the 26 Mar 08 at 14:57:
> One of the best ideas, I've seen on Launchpad.
> This is definitely something we need.

Yeah, I think this is something that is really important for new users. I believe that if we develop a reasonable spec for doing this that it could really catch on. This same technique could also be implemented for embedding the "*.glade" file used by libglade applications into the ELF file, removing the necessity for having a folder with additional application resources.

jrusinek wrote on the 26 Mar 08 at 16:07:
> Why copying Windows is so much needed for you?

I haven't seriously used Windows in like 7 years. This issue is a matter of usability for new users, I normally use the terminal for just about everything and don't even notice this for the most part. Ubuntu is a project that tries to make a comfortable operating environment for everyone, not just for people like me and you.
]]> Wed, 26 Mar 2008 17:07:18 +0000 This is not about Windows. This is about user-experience and usability. Don't bash ideas just because there may be something similar in Windows.]]> Wed, 26 Mar 2008 19:46:59 +0000
+1]]> Thu, 27 Mar 2008 20:20:13 +0000 Thu, 27 Mar 2008 21:57:30 +0000 I'd like to keep all binary files as binarys, with the same "binary file" icon, rather than having to think whether the file is a binary, an icon, or an image.

"The problem with that is that you cannot expect every software package to be distributed using the package manager."
That is the ultimate goal. All software makers should be encouraged to do proper packaging and distributing their packages thru official repositories. Less hassle for them, no need to host repositories. Repositories are the major feature of Linux distributions, that's why we shouldn't give up on them.

Also I'm not sure if changing the ELFs would not break binary compatibility between distributions.

I've voted against.]]> Fri, 28 Mar 2008 08:59:53 +0000 > This is IMHO a useless idea.

I respectfully disagree, it is useless for me but I know of plenty of people that this would be helpful for. The only way this might make my life easier (as a developer) would be for adding in resources such as *.glade files into a binary so the application doesn't need to look for them.

> There is no prove that binary's having icons help usability. Totally different programs can still have the same icon.

I have run into plenty of people that are confused that all linux programs have the same diamond icon.

> ... I'd like to keep all binary files as binarys, with the same "binary file" icon, rather than having to think whether the file is a binary, an icon, or an image.

Then if this gets implemented you can turn it off, just like you can turn of thumbnailing for pictures and PDFs.

> ... Repositories are the major feature of Linux distributions, that's why we shouldn't give up on them.

I'm not suggesting that we do, this idea is meant to augment existing packaging.

> Also I'm not sure if changing the ELFs would not break binary compatibility between distributions.

It would not, the technique discussed adds a new section to the ELF binary that is not referenced by the application code. This new section is handled kind of like debugging symbols, which you can optionally have in a binary without influencing its execution (you can even use "strip" to remove them from an application after it's made).
]]> Fri, 28 Mar 2008 16:40:38 +0000 These applications obviously don't have packages for Ubuntu. And now you're proposing to enhance Ubuntu's binarys with icons. What's the point of this if those who didn't care to prepare debs for Ubuntu still won't care to make their binarys with icons, since that feature will be only in Ubuntu (at least in the beginning)?
You would have to encourage every distributor of Linux software to change their binarys. If you want to encourage them to anything you should better encourage them to prepare Ubuntu packages.]]> Sun, 30 Mar 2008 10:50:10 +0000 > ... What's the point of this if those who didn't care to prepare debs for Ubuntu still won't care to make their binarys with icons, since that feature will be only in Ubuntu (at least in the beginning)?

Every idea has to have a beginning somewhere. This kind of thing is something that could conceivably be folded into automake, so a developer would just need to add something like "progname_ICON = 32 iconfile.png". However, this does not to be implemented by developers in order for it to be useful. An icon can be retroactively added to an application, providing a consistent icon throughout the entire UI (something that we do not currently have).

> You would have to encourage every distributor of Linux software to change their binarys.

In order to take advantage of this feature you would want every developer of GUI applications to add this section to their binary. I believe that there is enough benefit to doing this that, given distribution support, developers would do this. However, this is kind of like recycling - every little bit helps even if you don't have everyone doing it.

> If you want to encourage them to anything you should better encourage them to prepare Ubuntu packages.

As much as it would be nice to convince every developer to make an Ubuntu package for their software, this will never happen. There are just way too many distributions to support in making packages, and few developers want to get involved with the war of the package managers. This particular idea avoids the package manager war: if the distribution supports the idea then the app will have a consistent icon no matter what packaging they use, if it does not then the icon must be set by the packager just like things are done now.
]]> Sun, 30 Mar 2008 21:58:54 +0000
In order to take FULL advantage of this feature ...]]> Sun, 30 Mar 2008 22:01:57 +0000
You're using .desktop entries, not the binaries from PATH itself.

IMO that's stupid idea and I'm against from its beginning.]]> Tue, 20 May 2008 15:00:10 +0000
Linux is about flexibility. By integrating icons into binaries it opens up new opportunities and new ways of doing things. We should always promote ideas that may allow us to do new things.

I solute you comp, and anyone who wants flexibility, and better usability should vote this up. It doesn't hurt to implement it, and there is always a way to override it.


Azrael. I never make debs for my programs, and neither do many other developers I know. Because each package only works on 1 or 2 distro's properly. I'm not going to waste my time doing that. And Distro's differentiate themselves because of packages.


This standard however, could be adopted and be added to any distro, without any con's because its a neutral project, and only affects the top layer of the distro. Whereas, package management is a low level of a distro, so you need a different package for each distro.

This idea compliments my MenuToGo program I just finished coding (and will be launched tomorrow after I finish the release notes). http://sourceforge.net/projects/menutogo/

Combining this with my project, would finally open a new chapter in linux usability.

+1. At the very least, this adds flexibility. And if it wasn't a good way of approaching things, OSX, windows and many other OS's wouldn't be using it. This is obviously a good idea.

And if you aren't a coder and don't understand the benefits, make sure you understand them FULLY before voting. Don't read what me and other people here wrote before coming to a conclusion. Make sure you know why they are useful, shortcomings of the current method, and where this might help. Because I have seen a lot of incorrect arguments made on brainstorm, so make sure u fully understand what you are voting for. ]]> Tue, 20 May 2008 15:37:19 +0000
There are many whingers here I have seen who complain about linux not having their idea, but them being too lazy to code it themselves.

We need more people like it Compholio.

And for people who don't know how to code, they should pick up a C++ book and learn. It actually doesn't take long to learn (or even java which is easier).

The best way to get an idea out there is with a prototype. And since this has one available, people shouldn't particularly be voting it down without at least trying the prototype to get an idea of the general benefits.

Come to melbourne aus Comp, and I wouldn't mind going out to get beers ;) Good job mate. Its good to see us as the brainstorm community getting more and more organised, and the realisation, that nobody can get an idea done better then ourselves (and it takes a load off of Canonical too). ]]> Tue, 20 May 2008 15:44:31 +0000
While I would like to get a bit more involved in the community, I fortunately/unfortunately have obligations that will be keeping my occupied in my country for the foreseeable future. However, I am a researcher (Physics) in the US, so it is possible that I might get out for a conference at some point.]]> Thu, 05 Jun 2008 14:13:55 +0000
]]> Sun, 08 Jun 2008 14:57:05 +0000 Sun, 08 Jun 2008 15:05:26 +0000
As for closed source applications on Linux: let them work it out themselves. Not interested! :-)
]]> Fri, 27 Jun 2008 04:16:36 +0000
That would really help our cause alot. Whilst Ubuntu may be open source, a lot of users are closed minded.

Its good though that a lot of developers and less vocal users aren't so closed minded though.. ]]> Fri, 27 Jun 2008 05:16:10 +0000
Maybe there's some sort of confusion here (I get this from the comparison to Windows' distribution of applications), but I am not suggesting that configuration files be stored inside the ELF binary. I am only suggesting that actual application resources be stored in the binary. Application resources are things like icons, pictures, and glade project definitions - things that the application relies upon in order to operate, but does not change after distribution or share with other applications.
]]> Fri, 27 Jun 2008 22:52:18 +0000 take a look at what happened after I installed KDE 4.1. Thats absolutely appalling. The last OS I encountered that did rubbish like this was Windows 3.11 (a 20 year old operating system).

Embedding icons is the safest way of doing stuff, because moving stuff around wont break anything. And if you want to go off your custom theming nut, you can always set the system to default to external icons if they exist.

Seriously, this is kind of pathetic, if we want to attract the crowd, icons need to work consistently. I wouldn't DARE show ubuntu to anyone and encourage them to use it, when we still have major issues with problems as basic as icons. What happens when I try to drop 5 of these apps onto the panel, how do I tell them apart?

Get serious for a few minutes please people. We are currently lying to ourselves if we call this OK. In Windows 95 (and greater), and OSX, this problem never arises. ]]> Sat, 09 Aug 2008 01:02:30 +0000
This would enable Gnome to automatically suggest a name for a desktop "starter" icon created. Today you have to type the user-visible name, the command line and select an icon; with a name stored in the executable you just have to type the command line and Gnome would suggest the rest (you have to confirm and are allowed to change this, of course).

>> The last OS I encountered that did rubbish like this was Windows 3.11.
But in Windows 3.x the icons were already stored within the EXE files.
]]> Sun, 10 Aug 2008 19:09:00 +0000 Sun, 10 Aug 2008 23:27:14 +0000 Actually, my thought was that the entire list of 'program names' and other useful information could be stored in the executable if a standard mechanism was made for storing strings in different languages (this information is currently stored in the ".desktop" files maintained by the packagers). However, this idea is hard enough to push as it is so I have been holding off on putting it into the proposal.

all:
If anyone has any thoughts on promoting this idea I'm all ears, I'm not particularly prominent in the Ubuntu community so it's been difficult to get any significant momentum behind this.]]> Fri, 15 Aug 2008 04:45:42 +0000 Mon, 17 Nov 2008 16:11:21 +0000 If you have issues of concern over attack vectors then please take a look at the preliminary spec and bring up any problems you find. I doubt that I've missed any security issues here though, as no "add-in" executable code is run unless the user opts to run the application (which is no different from how things are now). Note that a flaw in rendering PNG or SVG images would also affect this implementation, but if you've got a problem with those libraries then you're already in serious trouble.]]> Mon, 17 Nov 2008 22:11:35 +0000 Mon, 17 Nov 2008 22:15:50 +0000
"Why copying Windows is so much needed for you?
You think Linux is OpenWindows?
Funny..."

I for one like very much this idea, it makes the files look better and not depend on external files and paths.]]> Wed, 11 Feb 2009 17:33:58 +0000 If you have any thoughts on promoting this idea then I'd appreciate it, as you can see this idea has been around for a while and hasn't gained much traction. The idea itself is not difficult to implement, as evidenced by my example implementation, but I think it's important to get some feedback before establishing something for everyone to standardize on.]]> Thu, 12 Feb 2009 19:29:48 +0000
I'm coming here from Bug 292504, which is about displaying the icons embedded in .exe files. They want to use the Gnome thumbnailer, which I think is a bad idea.

One thing to remember is the Trojan horse factor, where executables in Windows masquerade as jpg files to encourage users to run them. In Linux, this is even worse, since file extensions don't matter. (Your friend's compromised computer sends you an email with OMG_this_chick_is_hot.jpg, which is actually a malicious shell script, for instance.) Allowing it to set its own icon makes for an even more convincing fake. I'm not going to be a moron and say that this is an insurmountable problem, but it should be kept in mind.

Should binaries really be executable directly? I thought the paradigm was to use launcher files (.desktop) to handle the icon and be the thing that the user launches. Maybe there's a completely different paradigm that could be used. Maybe when you view a folder, executable files should be in their own "pane" in the file manager, separate from documents, and with different functionality and appearance. Maybe a launcher should be created automatically when you try to run an executable directly.

If we want users to execute binaries manually, I'm imagining that there will be an "executable" emblem on all of them, to help remind users that they are executable, and then they could optionally set their own unique icon. Originally I imagined a Wine emblem for .exe files, for instance, but maybe it would be better to just have a uniform "executable" emblem that is the same for ELF binaries, .exe files, .py files, etc.

The emblems should be different depending on whether the executable bit for that file is set, and whether the required compatibility layer is installed (if you have a .jar file but Java's not installed, or a .exe file but Wine's not installed, for instance, it would show a "broken" executable emblem). Double-clicking one of these with a broken executable would start an installer for the missing component. Double-clicking one without the executable bit set would explain the dangers of what you're doing and ask if you want to make it executable.]]> Mon, 30 Mar 2009 15:06:33 +0000 I am only suggesting that actual application resources be stored in the binary. Application resources are things like icons, pictures, and glade project definitions - things that the application relies upon in order to operate, but does not change after distribution or share with other applications.

Why does it matter? Any program you're distributing is going to be a package of multiple files, whether it's a .deb or a .zip. What's the benefit over including a .desktop launcher and an icon as separate files? Put all the system files in a subdirectory, and leave only the launcher in the zip file's root.]]> Mon, 30 Mar 2009 15:22:32 +0000 > One thing to remember is the Trojan horse factor, where executables in Windows masquerade as jpg files...
Provided that web applications follow the standard guidelines and do not set the executable bit on the application, then directly downloaded files will not execute when clicked. You will notice that with Firefox or Thunderbird (or other app of your choice) that with any file that you download that you cannot run it until you manually make it executable.

> Should binaries really be executable directly? I thought the paradigm was to use launcher files (.desktop) to handle the icon and be the thing that the user launches.
That's currently the only way to do things, and in my experience it is not sufficient for new GUI users. This method also results in inconsistencies in how icons are displayed depending on how you find the application.

> Maybe a launcher should be created automatically when you try to run an executable directly.
You cannot make a launcher for an executable automatically if you do not have enough information about it. How do you propose to automatically locate the icon or the name of the application in different languages?

> If we want users to execute binaries manually, I'm imagining that there will be an "executable" emblem on all of them, to help remind users that they are executable, and then they could optionally set their own unique icon.
I am not opposed to adding a symbol on top of executable icons, but I do believe that we need to have user-recognizable icons built into the executable.

> Why does it matter? Any program you're distributing is going to be a package of multiple files, whether it's a .deb or a .zip. What's the benefit over including a .desktop launcher and an icon as separate files? Put all the system files in a subdirectory, and leave only the launcher in the zip file's root.
From a developer perspective does this is a pain in the butt, you'll notice that most developers ignore these issues and just leave it up to packagers to do this for them. Distributing an executable that has its major resources included with it makes things much easier for everyone.]]> Wed, 01 Apr 2009 20:29:13 +0000 From a developer perspective does this is a pain in the butt, you'll notice that most developers ignore these issues and just leave it up to packagers to do this for them. Distributing an executable that has its major resources included with it makes things much easier for everyone.

I really don't see why. It takes a minute or so to create a launcher and connect the icon to it.]]> Tue, 07 Apr 2009 18:11:16 +0000 > > From a developer perspective does this is a pain in the butt, you'll notice that most developers ignore these issues and just leave it up to packagers to do this for them. Distributing an executable that has its major resources included with it makes things much easier for everyone.
> I really don't see why. It takes a minute or so to create a launcher and connect the icon to it.

Except that you have a couple rather significant issues:
1) Launchers do not support relative icon paths
2) Including the icon separate from the binary requires that the application either find the icon on the filesystem or duplicate the icon in the binary.

For many applications you just have the executable itself, forcing the developer to add a separate file (plus an icon) just to make things look nice is plain silly.
]]> Tue, 07 Apr 2009 22:48:50 +0000
Just because its possible to do it another way, doesn't mean we shouldn't strive for the best way, especially when the current way doesn't work well anyway]]> Tue, 07 Apr 2009 23:40:41 +0000
What ideally would applications do when you download/install them? Not from a developer perspective, but from a user perspective. Something like:

1. Click on a link
2. It downloads with a progress bar and then installs after making sure you know what you're doing
3. You have an icon in your menu/search tool which you use to start the program

I don't see a reason why a user should be digging around in folders to find executable files and launch them manually]]> Wed, 08 Apr 2009 04:52:19 +0000
Name 1 good reason. This is what i don't get about linux people. There is no good reason not to atm.]]> Wed, 08 Apr 2009 08:16:43 +0000
I think that .deb files with icons could be _great_ though, as long as they have some kind of emblem on them to indicate they are .deb files. Perhaps even an animated icon that swaps back and forth between the default .deb icon and the application icon?]]> Thu, 04 Jun 2009 22:05:38 +0000
http://launchpadlibrarian.net/27145693/computer.png]]> Fri, 05 Jun 2009 02:02:31 +0000
The executable is NOT the program! This is a design issue in Windows. Adding icons to executables will only clone this misconception into Linux. For the novice user, the executable should be an opaque component of the program. There should never be a need to intract with it directly from the file manager.

"Actually, my thought was that the entire list of 'program names' and other useful information could be stored in the executable if a standard mechanism was made for storing strings in different languages (this information is currently stored in the ".desktop" files maintained by the packagers)."

The program name for the launcher is currently stored in that program's gettext file, and the launcher file includes an X-GNOME-Gettext-Domain entry that tells the panel in which gettext domain to look for a localized program name. Embedded translations are wrong because you can't delete the translations you don't need.

"Except that you have a couple rather significant issues:
1) Launchers do not support relative icon paths
2) Including the icon separate from the binary requires that the application either find the icon on the filesystem or duplicate the icon in the binary."

Using relative paths in launchers is WRONG. The proper way to ship an icon is to put it in /usr/share/hicolor/(size dir)/apps, and put only the icon's basename in the Icon field. This way your icon can be themed. As for the application, you need to use gtk_image_new_from_icon_name and GTK will find the proper themed icon for you. Don't know about other toolkits, but they should be similar.

"I think that .deb files with icons could be _great_ though, as long as they have some kind of emblem on them to indicate they are .deb files."

A better idea would be to extend the APT repository to optionally provide an icon list along with the package list. This way, the crude hack of app-install-data could go away since this data could be pulled from the APT repository. Some way of diffing the list should be provided though, so that only the icons that changed / were added need to be re-downloaded.]]> Wed, 10 Jun 2009 12:37:41 +0000
GUID is a proprietary implementation of UUID by Microsoft. On top of that, it is inferior to using the application's executable basename, which should be unique anyway.]]> Wed, 10 Jun 2009 12:49:34 +0000
What you are effectively saying is that ALL programs in linux should be installed via a deb before using them, no matter how tiny they are, or if they wont be used again. Nooo.. They must ALL be installed as root. That way when non-root users want to do anything they cannot.

Great way to encourage privilige seperation. Encourage users to use administrative privileges as often as possible. Never mind that the user may be just running a quick tool to upgrade the firmware of their printer. NO, the firmware upgrade program MUST be installed (apparently).

Sorry, but I am close to tears. Even a blind man could see the error in your argument. And for me as a developer, I refuse to have to distribute my programs as an archive/package just to make things as usable as possible.


]]> Wed, 10 Jun 2009 14:16:32 +0000 I promote a project called SFS Technology here:
http://brainstorm.ubuntu.com/idea/20108

Can we implement your great idea also on some squashfs filesystem (SFS Technology executable files) ?
If yes please contact me!

Bye
Vincenzo]]> Wed, 10 Jun 2009 20:42:34 +0000
There is no reason why developers shouldn't be able to add icons to their apps, there is no reason why programs should be installed before using always (Songbird/firefox is an example that proves that, because it can't be easily upgraded if its installed as root), and programs shouldn't be executable, and the only design issue I see in this whole thread, is that small, but incredibly major stuff like running programs is still overly complicated on linux.


I hear people talk about linux one day being a dominant filesystem. Well, the majority of people who start talking about usability in linux, still get it totally wrong. Its no longer the 1960's, and we should stop treating Linux like an obsolete mainframe. ]]> Wed, 10 Jun 2009 23:45:20 +0000 People arguments "everything should be a distro" is silly. I have a personal app I made that has both windows and Linux compiled executable which access same database for my usb.

This way I have something very portable and user friendly. Many other things like portable firefox could have similar thing.

I think icons are very friendly and improve the user experience helping them identify what they are looking for.

I think it is a bad idea on linux because executables have no extension. if an app had a picture of a folder and is a malicious. You can not visually tell if it is a folder or not when browsing. On windows this is acceptable(as long as hide known extensions is off, which it is not by default and I have seen malicious software spread well).

If icons were to be added. There would need to be an overlaid icon to say it is a executable.

]]> Thu, 18 Jun 2009 00:22:03 +0000
Someone commented about compatibility between distros.
1. You can make it so it does not effect normal running of an applcation.
2. You can not guarantee Compatibility between distros anyway.]]> Thu, 18 Jun 2009 01:04:20 +0000 Thu, 18 Jun 2009 07:43:07 +0000 > Someone commented about compatibility between distros.
> 1. You can make it so it does not effect normal running of an applcation.

Correct, this change does not affect the normal execution of an application. You can actually apply icons to existing applications without harming them, thanks to the wonders of the ELF specification. So the only difference would be that some distros would support the icons (or other resources) and other distros would only be able to treat the binaries as normal executables.

> 2. You can not guarantee Compatibility between distros anyway.

Most distros follow the Linux Standard Base, any application that follows these requirements will run on "any" (almost all) distros.
]]> Fri, 19 Jun 2009 15:17:54 +0000
I've been working on an application that acts as a launcher for a larger applications. It uses libfuse and libzip to mount a virtual filesystem (based off a zip file integrated with the executable), and runs an executable inside the zip (likely either an installer or the application itself).

The basic idea is to provide a fairly bullet proof launcher for a larger application, run from just about any distribution and from anywhere in the system tree, all while only using a single file. This is similar to SFS Technology linked earlier in this thread, but requires nothing additional to be install by the user.

This would never, ever replace deb files or packaging in general. It would, however, be nice for distributing applications that don't interact with the rest of the system, and aren't updated very often (or at all). Examples include a portable version of Firefox, and one of the many small scale SDL based games.

At the moment, the biggest roadbump is the icon (well, that and downloaded executables require a few not necessarily intuitive clicks to actually run, but that's a different topic). .desktop files don't work since it would require at least three files (executable/launcher, .desktop, and the icon), not to mention trying to keep its executable and icon paths correct when all three are moved.

This solution would work very well. Only issue I can see is whether it would interfere with distros that aren't aware of the icons, though that doesn't appear to be the case.]]> Mon, 10 Aug 2009 02:29:43 +0000 Thu, 10 Sep 2009 21:37:40 +0000
When you install a package with a package manager, unless it was a CLI app, it will probably have an icon for your menu. An example earlier about how KDE 4.1 .desktop files, by default, were broken in GNOME was a KDE problem. The reason why so many applications use .desktop is because it is more organized (at least from my perspective), easier to modify, and more centralized than the method Windows uses.

I, for one, almost "never" need to run an executable manually by searching through a folder or two to find it, mark it as executable, and open it; if this is the case with most Ubuntu users, then I don't see a reason for things to change. Even still, it's possible for these ELF files to use .desktop files for menus such as when I installed Adobe AIR, which not only installed icons for it, but it installed icons for the other programs I might install.

Another issue is the fact that this would encourage breaking away from package managers. Repositories and package managers are safe, secure, and easy. Why should we use anything else?

Also, on a semi-related note, the *last* thing I want on linux is an equivalent to Windows' TERRIBLE "Autorun". Does it look like I want malware on my machine, people? Things like this are the reasons why Windows is so insecure and why so many people (myself included) use Linux. If we adopt things like this, then not only will standards be broken but Linux would be terribly, terribly insecure.

Simple != secure, and I hope it stays that way.]]> Wed, 14 Oct 2009 20:47:19 +0000
- Use of embedded icons can work in tandem with systems already in place. The file manager can look for a .desktop file and if none is found then try the executable itself. Thus nobody is *required* to use this method, but it can be *available* to those who wish to.

- There are ways to mitigate security issues that aries with custom icons. Binaries with custom icons can still be marked as binaries, maybe via a label color, a background colour, one of those tiny marker images etc. Also does the standard binary executable icon really stop your average naive user from double-clicking that "greeting-card" trojan?

- There are potential performance improvements. To give you an idea:

mslade@binks:~/t/elfrctest/elfrc$ find /usr/share/icons -type f|wc -l
5326

A lot of these icons are the various formats of icon installed for each application. If these could be folded into the application binary itself, it would save a lot of inodes, slack space, hdd seeks, dpkg/info data, etc

(This is one of my pet peeves - boy that "reading package database" bit sure does take a while)

- This should be done right. I think elfrc as used in the implentation given just adds the icons to the initialised data - so it gets mapped into memory with the rest of the binary. the ELF ABI provides ample opportunity to embed data into the executable file without it getting loaded into memory on execution.

Also the way the icons are stored in the file should probably not make too much use of the ELF data structures - a single ELF section would suffice. The section data would be opaque to ELF and any loaders, linkers etc, and would contain all of the icon data and metadata necessary to select, retrieve and display icons.

Also ".icon" is technically not allowed as a section name, anything beginning with "." is reserved by the ELF ABI.

- There's nothing stopping anyone from using libbfd and a bit of voodoo to create an ELF binary with self-embedded resource data to be used by the binary itself. Why doesn't anybody ever do this? I don't get it. Self extracting executables!
]]> Fri, 23 Oct 2009 14:58:07 +0000
Sorry if my assumption's off, but I still don't see why anyone would need to have this. If the application's installed /the right way/ then there shouldn't be any problems finding the right executable, much less executing it (from the applications menu).]]> Sat, 31 Oct 2009 23:30:37 +0000
And yes, as mentioned, this doesn't make things less secure because an emblem can be added. However, binaries downloaded from the internet SHOULD be +x, and instead, should be tagged as internet downloads so users are warned.

+x IS A SECURITY HACK!! We need to start doing things properly. ]]> Sun, 01 Nov 2009 03:23:08 +0000 > ...
> A lot of these icons are the various formats of icon installed for each application. If these could be folded into the application binary itself, it would save a lot of inodes, slack space, hdd seeks, dpkg/info data, etc

If I get some free time again then I'm looking into making this "even better." By allowing you to create a "one canvas" SVG file you wouldn't even need to embed separate icons, the library would strip each icon out of the SVG file and you'd be set to go.

> ...
> This should be done right. I think elfrc as used in the implentation given just adds the icons to the initialised data - so it gets mapped into memory with the rest of the binary. the ELF ABI provides ample opportunity to embed data into the executable file without it getting loaded into memory on execution.

The sections are created with the flags "SEC_HAS_CONTENTS | SEC_DATA | SEC_IN_MEMORY", where "SEC_IN_MEMORY" tells libbfd that it is to build the section data from a pointer - not that the loader should load the section into memory. I do not intend to have the loader automatically load the sections into memory, so if I have made a mistake somewhere then please let me know.

> Also the way the icons are stored in the file should probably not make too much use of the ELF data structures - a single ELF section would suffice. The section data would be opaque to ELF and any loaders, linkers etc, and would contain all of the icon data and metadata necessary to select, retrieve and display icons.

I considered that, but I wanted to make it so that a very minimally application could obtain the icon. I have not added it yet, but a helpful individual contributed some code that is a minimal "grab a section" example. This kind of approach would be nice for a minimal read-only ELF backend that is statically included into a binary (such as a self-extracting executable).

> Also ".icon" is technically not allowed as a section name, anything beginning with "." is reserved by the ELF ABI.

I disagree with your interpretation, the specification states:
---
Section names with a dot (.) prefix are reserved for the system, although applications may use these sections if their existing meanings are satisfactory.
---
I would say that a library for reading and writing resources is "part of the system," so standard things like icons should be included as system sections.

> There's nothing stopping anyone from using libbfd and a bit of voodoo to create an ELF binary with self-embedded resource data to be used by the binary itself. Why doesn't anybody ever do this? I don't get it. Self extracting executables!

I'm not sure, maybe because they prefer self-extracting shell scripts (something I find absolutely abhorrent). It could also be because libbfd is a pain in the butt to use, I know I originally developed this example using libelf and added support for libbfd (now the default backend) when I discovered that libelf had a tendency to corrupt small binaries. You might note that creating a self-extracting executable with libr is really easy.
]]> Tue, 10 Nov 2009 20:25:27 +0000
@Solution #1 : Please, according users never will seen ELF binaries. Users can run program only by terminal or by icon, not by ELF executable. If we need to install a program, we downloads .run, .bin or .deb file(never ELF).]]> Wed, 11 Nov 2009 09:24:13 +0000 > Please, according users never will seen ELF binaries. Users can run program only by terminal or by icon, not by ELF executable. If we need to install a program, we downloads .run, .bin or .deb file(never ELF).

Open a terminal and run "file ", you will get a response similar to this:
----
: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, stripped
----
In other words, ".bin" files are self-extracting ELF executables (these days they're usually made with Icculus' MojoSetup). A ".run" file is a self-extracting shell script (which I personally find horrid, but to each their own). However, in my experience a vast majority of the time I find a binary download for Linux it's a whole collection of files in an archive (.tar.gz or .tar.bz2) where the ELF executable is located at the top level.

I'm likely not a typical user, but have you never used "Open With" in Firefox to find an application like /usr/bin/gedit because the default did not suite you? Wouldn't it be better if Firefox could load the entire list of executable files in the $PATH and apply the appropriate icons and the names of the applications in the local language?
]]> Wed, 11 Nov 2009 18:08:18 +0000
Open a terminal and run "file name_of_bin_file", you will get a response similar to this:
----
name_of_bin_file: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, stripped
---- ]]> Wed, 11 Nov 2009 18:09:53 +0000
We can only run it by terminal emulator/real emulator.

Only exception is Nvidia drivers installer, but it should also be possible to install via console.]]> Fri, 13 Nov 2009 18:19:47 +0000 Fri, 13 Nov 2009 19:20:33 +0000