There are, at least, two things this could be. The most likely is that ps is aliased to ps -A (or ps a; the a without the - results in behavior similar to -A) on fedora; which would explain the output format. On each system type which ps which will reveal what aliases if any are being called instead of the executable directly.
You can bypass any aliases by either either calling the full path of the program (e.g. /bin/ps or by starting the command with a leading '\', e.g. \ps.
The far less likely thing is that the two distros compiled ps with different flags (resulting in different behavior). I just checked ps on fedora 23, and it's default output is the same as what you are getting from ubunutu, so I think you have an alias set.
The alias is most likely set in the file ~/.bashrc; although other locations are possible. You can see the aliases in your current environment by typing alias with no arguments in the terminal.
Update:
Since they aren't aliased, something else (to state the obvious) is modifying the behavior. Here are a few things to look at to find out what that is: On each system, run them in a 'clean' environment:
env -i ps and see if the behavior changes. If it does, then we know it's an enviromental setting changing it.
on each system, enter the following command: ps --info
See if the field personality=0x field is non zero which can change the output. Note any other differences from that output; post them if you can't decode the meaning of the difference.
To see if something is re-purposing ps, run the following in the bash shell on each:
set -x ps -a You should see something like:
+ps -a echoed out; if you see something else, e.g. +ps aux, then that would cause this. That is usually done by an alias but it could be a function. You can turn off the bash spam by running set +x
On each machine check if the binary is an symlink to something else and if there is something odd going on there (likely on fedora that /usr/bin/ps is a sym link to /bin/ps)
ls -alt /bin/ps ls -alt /usr/bin/ps Try
type ps On each machine; the results should be the same, if not respond with the results.
There are some enviromental variables that can modify the behavior of ps; to see these type man ps; they are at the bottom. type env on each OS and see if any are set; you can grep for them:
env | grep 'CMD_ENV\|PS_PERSONALITY\|_XPG' There are others; see the manpage to add them to the query if these return nothing or to figure what the setting means to ps.
Getting into the weeds here, but if you still have nothing, check the binary file headers on each:
readelf -h /bin/ps If none of that shows any differences, you can copy the /bin/ps file to the other OS and do a compare:
cmp -b /bin/ps /path/to/copy/of/ps That will output all of the bytes that differ between the two files. The actual values don't matter; just the number of differences.
They will be different; if it's only a couple bytes difference than that would just be the gcc field NT_GNU_BUILD_ID which is unique for every build, even otherwise identical files. If they are not substantially different than it's an environmentally influenced behavior, and I can't think of anymore to check.