Originally posted by theedudenator I need to do some reading on how to install stuff.
Understand how Windows "installs stuff" is
the exception, not the rule. In "real OSes" where we care about security -- especially authenticity and non-repudiation -- we only use a pre-installed tool on the system to install "packages" that are "digital signed" with pre-installed keys on the system. We
never trust
The most Microsoft provides is a "right-click" on an .exe file to inspect any
optional signature. If someone doesn't do that, it will straight-up install. On the .inst/.msi "packages" (which is an insult to the term "package"
), digital signatures are still optional and you won't get a warning unless you change defaults. It's rather pathetic and a joke to anyone who maintains any number of systems on a corporate network.
Because of this "automation by default, overriding security," it's how the overwhelming majority of Windows systems are infected in the world. Even when you turn off various features in MS IE, some capabilities are left on because it would break Windows automation. It's part of the core Windows executive in the kernel. If Microsoft turned those off, it would utterly render most features in Outlook and other programs useless. They've tried private Alpha tests.
Originally posted by theedudenator I can't seem to figure it out.
I am also not sure what the best directory structure is yet.
POSIX (UNIX) and GNU (UNIX-like) systems have a
mandatory filesystem hierarchy standard. Under Linux, this is the Filesystem Hierarchy Standard (FHS), which is recognized by Linux Standard Base (LSB) and most others.
NEVER DEVIATE FROM FHS, PERIOD!. If you do, you deserve what you get.
Programs provided by the OS distributor install under /usr.
Programs provided by third party distributors (such as software vendors) install under /opt.
Programs built by a site, or possibly community distributed, install under /opt or /usr/local.
Standard subdirectories are ./bin (binaries), ./doc (documentation), ./lib (libraries, possibly ./lib64 for x86_64 on Intel/AMD), /sbin (superuser binaries), and several others.
Yes, this means different programs are "mixed" under those directories. The packaged program is managed by the package management system -- every file for every package, to a scientific singularity. We don't have all these "rogue" files and non-sense like in Windows systems. It may seem "stupid" to home users, but when you're managing 15,000 Linux systems on Wall Street versus 7,000 Windows systems, you can do the former with 1/10th the staff because of strong package management (even before looking at system integrity/security
).
System-wide configuration files drop in /etc.
User configuration files
always go in the user home directory ($HOME).
Those should be the only variations from the package software.
And problem the #1 biggest difference (especially security wise) is that only Windows requires a "start-up" directory, which many Windows programs (including ones built by MS tools in Visual Studio) assume it has "write access" to. In the POSIX/GNU world, we
never require a "start-up" directory, and it's definitely
never the directory "where the binary/app is" because POSIX/GNU systems [b]assume you a user
cannot write anywhere exept their home directory and/or /tmp
by default
Remember, Linux is not Windows. Linux is
not trying to "be like Windows" either. Even MacOS X, based on Darwin (a lineage to the NeXT which was based on BSD/UNIX) does not attempt to be like Windows either. The Windows model is
not a good one to follow. Even when Microsoft tried to make NT better, their own app and tool developers
ignored the APIs and security standards because "they got in the way" (long story, I saw it happen first hand).