Earlier quoted context omitted.
I do not want any of that stuff. I found FreeBSD to be unusable simply in the command line environment. I was using only a text console login. I simply wanted a decent shell and editor. Heck, FreeBSD wouldn't even scroll back with the de facto standard Shift-PgUp. > mounts his drives for him That amazing advancement in Unix usability can be achieved by something called the "automount daemon" which was introduced in t…
> I found FreeBSD to be unusable simply in the command line environment. I was using only a text console login. I simply wanted a decent shell and editor. If you don't like a command line interface install a desktop environment, if you want a different shell install one and if you wan't a different editor, again install a different one. Nothing you have wrote suggest FreeBSD is unusable, apparently you prefer systems…
> If you want a different shell install one and if you wan't a different editor, again install a different one.
I didn't want to customize the FreeBSD environment because I was only using to to maintain a port of a specific program. I wanted that to build in the vanilla environment and not have any dependency on some customizations.
Dealing with FreeBSD was just a hassle, even for the three or four minutes once in a while (at release time) to fire it up, pick up new code, build and go through the regression suite, then roll binaries.
The last straw was when I switched some parsing to reentrant mode, requiring a newer version of Flex than the ancient version on FreeBSD. There was no obvious way to just upgrade to a newer version without building that from sources. That's okay, but it means anyone else wanting to reproduce my steps would be forced to do the same. Everyone else has newer flex: no problem with the GNU-based toolchains on Mac OS, Solaris, and elsewhere. MinGW, Cygwin, you name it. On Ubuntu, old flex is in a package called flex-old, which is mutually exclusive with a package called flex.
I just said to heck with it; I'm just not going to actively support that platform.
Actually, that was the second to last straw. The BSD people also don't understand how compiler command line feature selection macros (cc -D_WHATEVER) are supposed to work.
If you don't have any feature selection, then you get all the symbols. The presence of feature selection macros acts in a restrictive way: intersection rather than union semantics. If you say -D_POSIX_SOURCE it means "don't give me anything but POSIX source", and so if you combine that with another such option, you get the set intersection, which is useless. I ended up using -D__BSD_VISIBLE, which is something internal that you aren't supposed to use (hence the double underscore) which has the effect of making traditional BSD functions visible even though _POSIX_SOURCE is in effect.
On GNU and some other systems, you just add -D_BSD_SOURCE and you're done: those identifiers are added to what you already selected.
This is how POSIX says feature selection works: see here:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2...
"Additional symbols not required or explicitly permitted by POSIX.1-2008 to be in that header shall not be made visible [by _POSIX_C_SOURCE], except when enabled by another feature test macro."
Except when enabled by another feature test macro: they are additive, damn it!
The BSD stance is that "just don't put anything on the command line and you get all the library symbols. What's the problem?" (Like, some of them are specific to your OS and they clash with some of mine?)