General Info

M

madjack1

Hi guys,
I'm new to FreeBSD and Unix and have a ton of questions but the main ones that seem to be cropping up are in the compilation and upgrading on ports. Like when I run make config what do these options actually mean? It looks like these options could fork a system into a lot of different directions but without knowing how they work I'm pretty sure I'm wasting a lot of compile time going in directions I don't need. Like the option to use optimized C flags, is there any reason why a person wouldn't want an optimized compilation? I thought that was the whole reason to compile a program locally was so that it was optimized for that system. Assuming that everyone wants an optimized system evidently thats not what that option means. Also I notice that some of the options are linking to libraries that may or may not be installed and so far, if I know for a fact that I have a certain program or library installed I link to it, assuming that it gives some kind of functionality but then again I might be opening up some kind of security hole. I've been trying to read up on some of these libraries and what they do but I don't seem to see anything on these *.so file warnings that act as servers. So I might be pouring my whole system out to the net through some shared library acting as a server. Is there a URL I can go to, to find out how these things work?
 
Many questions, not all of them related but I'll give it a shot.

What make(1) does is read a file called Makefile. This tells make how and what to compile and link. The config is a make target. You can have multiple, different, targets in the same Makefile. This is a special one for the ports system. You can find more of them in ports(7).

As for the optimized C flags option, if it's an option it usually means it can cause build failures. But most of the time it works correctly. Because it can cause problems it's turned off by default. It's just the safer option. Which options to enable or not requires a bit of knowledge. If you don't know what an option does it's best not to touch it. Nevertheless, some options are quite simple to understand.

Libraries are nothing more than a collection of routines (APIs) that are re-usable by different applications. Why write your own if you can use a library that already contains the functionality you need? Figuring out what library does what is a great exercise but don't expect to understand everything. Even after 10-15 years of using FreeBSD I still don't know exactly what most libraries do. The important ones, yes, but everything else is just there because something I have requires it.
 
Building a port with a config screen option for optimizations means it might be able to run faster on that system. But sometimes the system building the port is not the one that will run it, and turning off optimizations will make the package capable of running on a different or lower-spec processor.

ports-mgmt/portaudit provides some automated reporting of known vulnerabilities. It will also prevent installing ports with known vulnerabilities.
 
First of all I want to thank both of you for the explanations. I've learned something new from each one of them.
@wblock - I understand what you're saying and it is good to know to use the defaults if I wanted to make my own precompiled packages. I suppose it would be a good way to update a lot of machines without having them down for any length of time. That is if there was something in the latest and greatest that a person would just have to have on these machines. Otherwise, personally, I would just stick with the precompiled packages from Freebsd even though they're slightly out of date.

@SirDice - I really understand what you're saying. I'm pretty familiar with the windows world and I don't know what all of those .dll's do and I really don't want to. I suppose, like you, I understand a few of them through experience, most of them bad, but anyway I managed to learn about the importance of and how to manipulate a few of them. The thing about the Unix's is that they're configurable; I don't know if this is better or worse. I was hoping there were written guidelines on how the configurations work, mainly for optimization but also for security. I do find it alarming how often in the upgrading process an installation installs one or more of those *.so files that can act as a server. I don't really mind the shared libraries so much as I would like to understand the environment that could cause serving off of the local machine. I don't know maybe I'm just being paranoid but I don't have a budget to pay a crew to constantly try to hack my machines to see if there are security holes. Also I'm not trying to imply that any of the coders have tried anything malicious in the coding process. As a matter of fact they've actually given us fair warning to remove the packages if we're worried about security. Unfortunately it's like you said, whether we know how they work or not we know we have to have them for the system to work. Oh well, I suppose the security process is the same no matter which OS is used, keep the valuable data away from the internet.

Thanks again - I'm off on my journey to learn how this new style works.
 
You must log in or register to reply here.
Back
Top