# Good source for best OS practices?

This topic is 1239 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I have mainly been a Windows user/developer most of my life. Recently I have started to use Linux almost exclusively for both general purpose use and development. I'm a little worried that I might be trying to run and distribute programs and such in a way that too much resembles Windows knowing full well that things are done differently on Linux in many ways.

Is there a good source for best practices for building, running, and distributing programs on Linux? And likewise, is there similar information for other OS's like OSX and perhaps even Windows as well?

##### Share on other sites
I have seen multiple techniques for distributing software in Linux / UNIX.

1) The most standard way
/usr/local/bin (binaries)
/usr/local/share/<gamename> (data files)
/usr/local/etc/<gamename> (global config files (optional)

This is sometimes a pain because it spams the filesystem with files and if you try to move it, often the paths are hardcoded at compile time so they will look in the wrong locations.

2) The common way for ported software
/opt/<gamename> (everything dumped in here)
/usr/local/bin (simple script added here to set paths and run game)

I personally do not mind this too much. It keeps the proprietary software away from the rest of the operating system. Typically used by software such as acrobat reader, skype etc...
This solution is also good for developers who use non-native (to UNIX) languages such as Java, .NET etc...
I see a lot of indie games written in Mono which distribute an entire implementation of the mono runtime with the game. I much prefer this to having to install mono on the system. I would also quite like to see Java developers distribute their games with an entire JRE. For an extra ~10 megs, it saves some pointless headaches for the user. Almost all software on Windows provides its own msvcrt.dll (C runtime) so the duplication is massive... but who cares right? At least the developer knows that the correct runtime will be used when the user double clicks the game haha.

3) The portable binaries way (kinda a hybrid)
[...]/bin
[...]/share/<gamename>
[...]/etc/<gamename>
[...]/lib

When the application runs, it works out its own path and works out paths to external files at runtime. This allows it to be moved to wherever, /opt, /usr, /usr/local etc... without breaking hardcoded paths.

The hardest thing about this is getting a program to work out where it "lives". I use the following code...

https://github.com/osen/mutiny/blob/master/src/mutiny/Application.cpp
(have a look at void Application::setupPaths())

It may look quite crazy but this is not an easy task to solve in a portable manner (things like procfs only really exist on Linux so I needed something that worked on the BSDs too). Feel free to ask any questions about it.

I also use this method for software on Windows. It works quite nicely and gives it a bit of a UNIXy twist ;) Edited by Karsten_

##### Share on other sites

s there a good source for best practices for building, running, and distributing programs on Linux?

The most common way to distribute software on a GNU/Linux OS (as opposed to, say an Android/Linux OS) is as a "binary package," usually served from an archive of such packages and accompanied by security measures to make sure it's legitimate and has not been tampered with.

You might want to learn about what goes into a binary package and how to create one, it's a nice little insight into how things in the GNU/Linux world in general works.  The most common GNU/Linux OS you'll encounter is Ubuntu, which is based on Debian, and in turn has its own derivatives (bundles with different desktop shells) and derivates (third-party bundles with different desktop shells).  You might read the Debian New Maintainer's Guide for a technical run-down of how the packaging works.  There's also the Ubuntu Packaging Guide.  Other GNU/Linux OSes such as Fedora use a binary package format called an 'RPM' which is similar but entirely different.