3 ms·

I really hate it when major PC vendors name autorun tasks (or really any background task) with cryptic names that don't clearly identify the vendor and applicat

I really hate it when major PC vendors name autorun tasks (or really any background task) with cryptic names that don't clearly identify the vendor and application. Yes, I realize we can't trust the name is legit without further verification. But when it is legit, knowing the vendor and app identity right in the name saves time. It would be nice if ALL applications did this but I can forgive a small open source project not doing so. However, when a Fortune 500 tech company with millions of users does it, it's unforgivable. It costs nothing to make your user's lives just a little bit easier. Also, for fuck's sake please populate the standard Window's file metadata for all your EXEs and DLLs when you're releasing products. I shouldn't have to run your app to find out the version number, vendor name, app name, release date, etc.

Joker_vD 2y ago
> the standard Window's file metadata for all your EXEs and DLLs when you're releasing products It has just occured to me that I don't know what are the ELF's counterparts of those fields... does ELF even have their counterparts?
- JoshTriplett 2y ago
  ELF doesn't have standard fields for describing where an executable came from. Linux systems haven't historically needed this, because every executable on the system (outside of the user's home directory or sometimes /usr/local) should belong to a package or shouldn't be there at all. So the typical Linux equivalent would be `dpkg -S /usr/bin/executablename`, or a similar incantation on RPM or pacman or ... Even proprietary software should be using a packaging system, whether that's the distribution packaging system, or some proprietary software containment system like flatpak/snap/etc. Such metadata would be more important on a system that regularly installs not just proprietary software but unpackaged proprietary software.
  - Joker_vD 2y ago
    > every executable on the system (outside of the user's home directory) should belong to a package or shouldn't be there at all. Is there any write-up about how this view came to be accepted in the most popular Linux distributions? Or, more generally, on the history of software packaging in the Linux world?
    - mike_hearn 2y ago
      Depending on your perspective it's either not unique to Linux at all (every OS now has an integrated package manager), or it's entirely unique (no OS not directly derived from UNIX uses the same design). It's worth remembering that Linux forks off from the AT&T UNIX design very early, and UNIX didn't have any notion of software management. It was an OS which assumed you'd compile programs yourself, probably because you wrote them yourself. It came out of a research lab funded by a government-granted monopoly, so it was designed for relatively expensive and powerful hardware. Like every early OS UNIX had very little in the way of userspace services so a pragmatic hack was to use the notion of well known directories to locate things like man pages or binaries. The concept of software being overlayed onto the same directory structure followed naturally from that, which means the FS doesn't have any metadata in it describing what belongs to what. Vendors viewed the problem of software management as primarily one of how to add and remove optional components supplied by the base OS, and how to execute upgrades. By that point the ship of sorting files by type rather than by component name had already sailed, so they added package manager databases on top to track the extra metadata the FS design couldn't. Microsoft and Apple approached things differently. The FS was in their conception primarily a way for users to organize their own files. DOS didn't offer any services that required registration so users got used to the idea of organizing programs into directories as they wished, and the background in cheap and heterogenous hardware meant that programs were often in semi-random locations determined by things like how many floppy drives or hard disks the computer owner had purchased. Thus when Windows came along and started offering integrated services, assuming specific physical locations on disk wasn't viable. So they invented the registry which served as the inverse of how UNIX did things: the registry was full of magic directories where small files could be placed to register things, and the FS was where the association between files and components (app folders) was kept. And it all sort of went from there.
  - ale42 2y ago
    This is the difference between /usr/bin and /usr/local/bin. The things managed by dpkg, rpm & co. go to /usr, and any non-packaged software should go to /usr/local (stuff built by compiling locally) or typically /opt (software supplied in binary form but not as a package). See for example the Filesystem Hierarchy Standard: https://www.pathname.com/fhs/pub/fhs-2.3.html https://www.pathname.com/fhs/pub/fhs-2.3.html.
    - Joker_vD 2y ago
      Wait, what does "local" mean in FHS? The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr. Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to replace or upgrade software in /usr. That is easily read as "non-system packages go into /usr/local", but that's obviously incorrect.
      - mike_hearn 2y ago
        It originally meant "local to your site" and was assumed to be a network mount.
      - Gormo 2y ago
        My understanding of /usr/local is that it's intended for software that's installed manually, outside the scope of the package manager.
- lmz 2y ago
  ident(1) and specially formatted string constants maybe https://linux.die.net/man/1/ident https://linux.die.net/man/1/ident
chrisml 2y ago
Once again the curious case of one hard thing in computer science:naming things.

Joker_vD 2y ago

> the standard Window's file metadata for all your EXEs and DLLs when you're releasing products It has just occured to me that I don't know what are the ELF's counterparts of those fields... does ELF even have their counterparts?

JoshTriplett 2y ago
ELF doesn't have standard fields for describing where an executable came from. Linux systems haven't historically needed this, because every executable on the system (outside of the user's home directory or sometimes /usr/local) should belong to a package or shouldn't be there at all. So the typical Linux equivalent would be `dpkg -S /usr/bin/executablename`, or a similar incantation on RPM or pacman or ... Even proprietary software should be using a packaging system, whether that's the distribution packaging system, or some proprietary software containment system like flatpak/snap/etc. Such metadata would be more important on a system that regularly installs not just proprietary software but unpackaged proprietary software.
- Joker_vD 2y ago
  > every executable on the system (outside of the user's home directory) should belong to a package or shouldn't be there at all. Is there any write-up about how this view came to be accepted in the most popular Linux distributions? Or, more generally, on the history of software packaging in the Linux world?
  - mike_hearn 2y ago
    Depending on your perspective it's either not unique to Linux at all (every OS now has an integrated package manager), or it's entirely unique (no OS not directly derived from UNIX uses the same design). It's worth remembering that Linux forks off from the AT&T UNIX design very early, and UNIX didn't have any notion of software management. It was an OS which assumed you'd compile programs yourself, probably because you wrote them yourself. It came out of a research lab funded by a government-granted monopoly, so it was designed for relatively expensive and powerful hardware. Like every early OS UNIX had very little in the way of userspace services so a pragmatic hack was to use the notion of well known directories to locate things like man pages or binaries. The concept of software being overlayed onto the same directory structure followed naturally from that, which means the FS doesn't have any metadata in it describing what belongs to what. Vendors viewed the problem of software management as primarily one of how to add and remove optional components supplied by the base OS, and how to execute upgrades. By that point the ship of sorting files by type rather than by component name had already sailed, so they added package manager databases on top to track the extra metadata the FS design couldn't. Microsoft and Apple approached things differently. The FS was in their conception primarily a way for users to organize their own files. DOS didn't offer any services that required registration so users got used to the idea of organizing programs into directories as they wished, and the background in cheap and heterogenous hardware meant that programs were often in semi-random locations determined by things like how many floppy drives or hard disks the computer owner had purchased. Thus when Windows came along and started offering integrated services, assuming specific physical locations on disk wasn't viable. So they invented the registry which served as the inverse of how UNIX did things: the registry was full of magic directories where small files could be placed to register things, and the FS was where the association between files and components (app folders) was kept. And it all sort of went from there.
- ale42 2y ago
  This is the difference between /usr/bin and /usr/local/bin. The things managed by dpkg, rpm & co. go to /usr, and any non-packaged software should go to /usr/local (stuff built by compiling locally) or typically /opt (software supplied in binary form but not as a package). See for example the Filesystem Hierarchy Standard: https://www.pathname.com/fhs/pub/fhs-2.3.html https://www.pathname.com/fhs/pub/fhs-2.3.html.
  - Joker_vD 2y ago
    Wait, what does "local" mean in FHS? The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr. Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to replace or upgrade software in /usr. That is easily read as "non-system packages go into /usr/local", but that's obviously incorrect.
    - mike_hearn 2y ago
      It originally meant "local to your site" and was assumed to be a network mount.
    - Gormo 2y ago
      My understanding of /usr/local is that it's intended for software that's installed manually, outside the scope of the package manager.
lmz 2y ago
ident(1) and specially formatted string constants maybe https://linux.die.net/man/1/ident https://linux.die.net/man/1/ident

chrisml 2y ago

Once again the curious case of one hard thing in computer science:naming things.