While the release happened last week, I haven't had a chance to install it until today. Currently my laptop only supports 32 bit virtualization, so I had to wait until I had an extra box to try it out on.
CentOS 7 is now up to date with some of the underlying technologies. systemd has been present since 2011 being first incorporated into Fedora 15 and other distributions following suit after that. This technology is probably going to be around for some time just as the Sys V Init scripts were. Another change has been that of making firewalld the default over iptables for firewall control. Firewalld is a very recent addition to Fedora coming in Fedora 18. Initially I didn't like firewalld because it wouldn't save some rules I needed for forwarding packets. That seems to be resolved now in Fedora 20 by being able to manually make permanent iptables rules through firewall-cmd. Before that you would have to revert to iptables to get things done.
With a minimal install I had some issues finding the MAC addresses for my network cards because ifconfig did not come installed. That may be intentional with the minimal install, but it is a tool I consider essential and should be included. I ended up having to go through /var/log/messages to find the MAC addresses so I could get it connected. Thankfully getting ifconfig installed just involves bringing in the net-tools package.
Aside from that everything has been working fine. Right now I am using CentOS 7 to setup a web server for a forum and possibly MediaWiki. It is a welcome change to CentOS 6 which is showing its age pretty well with the lack of new but foundational technologies.
Tuesday, July 15, 2014
Thursday, May 1, 2014
Basic Concepts for C Development
This is embarrassing to admit, but I didn't understand the basic needs of the compiler until recently. If you want to use make, automake or CMake (add whatever build system you want to use for compiling your C projects) to manage your projects, you need to have a mental model of what is going on. Without this model I have ended up spending hours just trying to figure out how to make my code compile with another library that I am playing around with.
When we write a C program, the compiler needs to be aware of where the headers are located, where the libraries that we are linking against are located and the source code that we want to build. All other details are less significant. The standard library is a blessing because you don't have to tell the compiler where to look for it as it already has the path built in.
Once you start working with other libraries this is no longer the case. To compile programs to use ncurses for example you need to add the -lncurses flag to the compiler. If you are dealing with SDL or GTK, you need to add more flags not only to indicate what library to link with (-l), but also other things that need to be defined for the library to work (i.e., GNU extensions). Programs like pkg-config will take care of this for you.
What has probably tripped me up the most though is knowing how stuff is included. When you use the preprocessor directive #include <yourheader.h>, it will search for that header in the standard include path. Being able to specify the include path is helpful when you want to select specific library versions such as including GTK2 over GTK3 or vice versa. The compiler is told where to include from using the -I directive. To be as accurate as possible #include "yourheader.h" allows you to look in the standard path and then the current directory you are working out of.
Knowing these things is important when telling your makefile where it needs to go to find these things so that you don't have to compile everything by hand. Without knowing these basics you will spend a lot of time fighting to compile rather than solving problems.
When we write a C program, the compiler needs to be aware of where the headers are located, where the libraries that we are linking against are located and the source code that we want to build. All other details are less significant. The standard library is a blessing because you don't have to tell the compiler where to look for it as it already has the path built in.
Once you start working with other libraries this is no longer the case. To compile programs to use ncurses for example you need to add the -lncurses flag to the compiler. If you are dealing with SDL or GTK, you need to add more flags not only to indicate what library to link with (-l), but also other things that need to be defined for the library to work (i.e., GNU extensions). Programs like pkg-config will take care of this for you.
What has probably tripped me up the most though is knowing how stuff is included. When you use the preprocessor directive #include <yourheader.h>, it will search for that header in the standard include path. Being able to specify the include path is helpful when you want to select specific library versions such as including GTK2 over GTK3 or vice versa. The compiler is told where to include from using the -I directive. To be as accurate as possible #include "yourheader.h" allows you to look in the standard path and then the current directory you are working out of.
Knowing these things is important when telling your makefile where it needs to go to find these things so that you don't have to compile everything by hand. Without knowing these basics you will spend a lot of time fighting to compile rather than solving problems.
Monday, February 17, 2014
Need help? Use proper English.
When different users seek help for their problems, it is critical that proper English be used. The reason for this is it is often not very clear what a user is asking when they post a question on a forum or ask in IRC. If the question isn't clear, a clear answer or no answer can really be given. Instead those users that are willing to help other users have to ask questions of clarification that make the process wearisome and unpleasant. With open source software you don't want to make the people supporting feel like it is drudgery to do so.
Most of what I have seen probably has more to do with foreigners who have not gained proficiency with the English language than anything else. At the same time though I have seen this problem with people whose native tongue is English. Unfortunately for other foreigners English has become the default language for anything to do with a computer. To a great extent that has to do with the fact that America has made a good number of contributions to computer science from programming languages and operating systems to establishing the framework of the internet. To get help and become proficient with a computer you need to have a mastery of English. This applies for reading documentation as well as asking questions.
The greater portion of questions I see are development related as that is my chief interest these days. Most new programmers when they ask their questions about how to hack in a given programming language (normally C) can't even hack together a good sentence in English. Being able to hack in C involves being able to hack in English. The programmers I tend to deal with that have achieved a mastery of C have at the same time demonstrated a mastery of English. Some of them are lazy with using that mastery, and others function as grammar nazis with what you write. Knowing English is key to obtaining knowledge of your desired technical field.
Most of what I have seen probably has more to do with foreigners who have not gained proficiency with the English language than anything else. At the same time though I have seen this problem with people whose native tongue is English. Unfortunately for other foreigners English has become the default language for anything to do with a computer. To a great extent that has to do with the fact that America has made a good number of contributions to computer science from programming languages and operating systems to establishing the framework of the internet. To get help and become proficient with a computer you need to have a mastery of English. This applies for reading documentation as well as asking questions.
The greater portion of questions I see are development related as that is my chief interest these days. Most new programmers when they ask their questions about how to hack in a given programming language (normally C) can't even hack together a good sentence in English. Being able to hack in C involves being able to hack in English. The programmers I tend to deal with that have achieved a mastery of C have at the same time demonstrated a mastery of English. Some of them are lazy with using that mastery, and others function as grammar nazis with what you write. Knowing English is key to obtaining knowledge of your desired technical field.
Subscribe to:
Posts (Atom)