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.
Wednesday, March 27, 2013
Scratching Your Own Itch
It has been said that most program development in the open source community has been done by individuals scratching their own itch. In other words when there was a need they came up with their own solution to that need. Linux itself is an example of that when Linus Torvalds wanted an operating system that took advantage of the specific features of a 386 processor. He released his code, so other students wouldn't have to reinvent the wheel, and they could play with it. A good number of us today use that kernel. Some things you may want may not exist on Linux, but if you are interested in taking the time and effort to scratch your own itch this post is for you.
Development of software on Linux can be done in almost any language. The Linux/Unix community probably supports more languages on their platform than Windows and Mac OS X do. Before you say it, I do know that Mac OS X is Unix, but unless you use Mac Ports there isn't much support for doing this. Two very popular languages for development are C and Python. These two have probably the most libraries out of the other languages. C++ can use C libraries, but libraries with C++ features are not as common.
Since you are going to probably want more than just command-line utilities you should know what toolkits you can use for making graphical applications. GTK+ is the library behind Gnome, Mate, Cinnamon, XFCE and LXDE. Currently there is GTK+ 2 and 3. 2 is still more common on the distributions that are not as bleeding edge such as Debian, Red Hat and its clones, Slackware and others. Depending on your target environment you may want to take that into consideration. GTK+ is written in C and works with it by default, but Python also has bindings to the library in a package called PyGTK. The other major toolkit is Qt which is what KDE is based on. Qt is written in C++, but it can be used by Python as well. Both toolkits will work on Windows if you install the libraries there.
Another thing that should be mentioned is Python has two versions that are being maintained and worked on right now. Those are 2.x and 3.x. 3.x code is not backwards compatible with 2.x, and not all 2.x code runs on 3.x. As of now, most libraries support the 2.x series, and this why sites like Udacity as well as books and tutorials teach version 2 over 3.
There are a good number of development environments on the Linux platform. I have tried IDEs and never really liked them, but some of the ones that I have tried are Eclipse, Anjuta and Netbeans. I use Emacs as my text editor, but Vim, gedit, Kate and others work well for that. Debugging I tend to do using gdb-tui or Insight. Python of course has its own interpreter, but there are a few other implementations out there though I have never tried them. The two popular C compilers right now are gcc and clang. They both have C++ and Objective-C compilers in the suite as well. I like clang better for the static analyzer that tells you more of what's wrong with your code or what can be problematic. Clang is also C99 compliant, but I don't believe it it has an option for C89 only code which gcc does. As for your build process, you will want to read up on makefiles. Make is the standard way of building on the Unix platform. There are other tools that make the process easier such as CMake and Autotools, but I have never used either.
Hopefully that is enough to get you started with your itch scratching. Between Google, some good books, Youtube, and some trial and error you should be good to go. Another helpful resource for finding headers or functions that you may need is the apropos command, but that depends on your already having the needed library installed. Devhelp is a good tool for reference with Gnome related libraries, but not learning how to use them. Happy coding!
Development of software on Linux can be done in almost any language. The Linux/Unix community probably supports more languages on their platform than Windows and Mac OS X do. Before you say it, I do know that Mac OS X is Unix, but unless you use Mac Ports there isn't much support for doing this. Two very popular languages for development are C and Python. These two have probably the most libraries out of the other languages. C++ can use C libraries, but libraries with C++ features are not as common.
Since you are going to probably want more than just command-line utilities you should know what toolkits you can use for making graphical applications. GTK+ is the library behind Gnome, Mate, Cinnamon, XFCE and LXDE. Currently there is GTK+ 2 and 3. 2 is still more common on the distributions that are not as bleeding edge such as Debian, Red Hat and its clones, Slackware and others. Depending on your target environment you may want to take that into consideration. GTK+ is written in C and works with it by default, but Python also has bindings to the library in a package called PyGTK. The other major toolkit is Qt which is what KDE is based on. Qt is written in C++, but it can be used by Python as well. Both toolkits will work on Windows if you install the libraries there.
Another thing that should be mentioned is Python has two versions that are being maintained and worked on right now. Those are 2.x and 3.x. 3.x code is not backwards compatible with 2.x, and not all 2.x code runs on 3.x. As of now, most libraries support the 2.x series, and this why sites like Udacity as well as books and tutorials teach version 2 over 3.
There are a good number of development environments on the Linux platform. I have tried IDEs and never really liked them, but some of the ones that I have tried are Eclipse, Anjuta and Netbeans. I use Emacs as my text editor, but Vim, gedit, Kate and others work well for that. Debugging I tend to do using gdb-tui or Insight. Python of course has its own interpreter, but there are a few other implementations out there though I have never tried them. The two popular C compilers right now are gcc and clang. They both have C++ and Objective-C compilers in the suite as well. I like clang better for the static analyzer that tells you more of what's wrong with your code or what can be problematic. Clang is also C99 compliant, but I don't believe it it has an option for C89 only code which gcc does. As for your build process, you will want to read up on makefiles. Make is the standard way of building on the Unix platform. There are other tools that make the process easier such as CMake and Autotools, but I have never used either.
Hopefully that is enough to get you started with your itch scratching. Between Google, some good books, Youtube, and some trial and error you should be good to go. Another helpful resource for finding headers or functions that you may need is the apropos command, but that depends on your already having the needed library installed. Devhelp is a good tool for reference with Gnome related libraries, but not learning how to use them. Happy coding!
Thursday, January 3, 2013
UTF-8: An Amazingly Simple Way of Internationalization
When you venture outside of the realm of the English language, it can be enough of a challenge just learning a new language, but imagine that challenge as a programmer who is trying to internationalize software. This was something I was faced with about three years ago as I started to develop learncurve, a program designed to make flash card review effective and efficient. As I started development, I already knew that the data type for strings in C can only hold 8 bit values. English doesn't need any more than 7 bits, but other languages have different writing systems that won't all fit in just 8 bits. So I began reading up on how to support these different languages. The answer was Unicode, but which Unicode?
For the first two and a half years of development I thought I needed to use the wchar_t type which depending on your platform provides a character that can hold 16 to 32 bits of information. I thought a char wouldn't cut it because I really didn't do my homework on Unicode. You see, I thought I needed UTF-16 because I thought UTF-8 was too small, but on doing more reading I found very little information regarding programming using UTF-16 or UTF-32 for that matter. Most of what I found was concerning UTF-8. Somehow I finally did more reading on UTF-8 and found out that it covers the whole Unicode character set using a multi-byte sequence to hold characters rather than a single char as in C.
In fact UTF-16 works this way as well, but since it is a larger data type it has to deal with those extra zeros the extra 8 bits bring along. This wouldn't be an issue except for how a computer deals with those zeros, and depending on the processor that you use it can make a big difference. For those familiar with the concept we are talking about big endianess and little endianess. It determines how a computer conceives the value of a sequence of binary digits to put it simply. After reading about the complexities of UTF-16, I decided to do more digging on using UTF-8.
Since UTF-8 could in theory handle all the characters in the Unicode character set only using char, I had to test and see if it worked. So I did a simple test, having it read in characters from Greek, Hebrew, Arabic, Chinese, and to really stress test it all the way past 16 bits of information I used Cuneiform. All of them displayed in the terminal just using normal char functions that are by no means supposed to handle wide characters. Now this approach does have its drawbacks. For starters we cannot index a UTF-8 string the same way we do a normal C string because of the fact it is mulit-byte. To extract a character out of a multi-byte string by array position, you would have to do some extra work. For my program it does not matter as I am not selecting character sequences that way. The other drawback is sometimes the terminal will not display a character high in the range correctly. This has more to do with the font that the terminal is using, but if you were to make a command line application using these high end characters such as the CJK block or Cuneiform, you would need to instruct the user to use the right font or find a way to set that for them. Another disadvantage is until the recent C standard (C11), support for Unicode string literals is not in C. With the new standard it is, but it will be sometime before that feature is supported long enough to use it in production C code.
Using UTF-8 in C is as simple as including the locale.h header and using the setlocale function. Here is an example:
#include <locale.h>
#include <stdio.h>
int main()
{
char buf[300];
FILE *fp;
setlocale(LC_ALL, "en_US.UTF-8");
setlocale(LC_CTYPE, "en_US.UTF-8");
setlocale(LC_MESSAGES, "en_US.UTF-8");
setlocale(LC_NUMERIC, "en_US.UTF-8");
setlocale(LC_COLLATE, "en_US.UTF-8");
fp = fopen("test.txt", "r");
while ((fgets(buf, 300, fp)) != NULL) {
printf("%s", buf);
}
return 0;
}
Using a UTF-8 enabled text editor you can save the language you want to test in there, and then have this code run. You will of course have to do more study for yourself, but hopefully this will give you the start that you need.
For the first two and a half years of development I thought I needed to use the wchar_t type which depending on your platform provides a character that can hold 16 to 32 bits of information. I thought a char wouldn't cut it because I really didn't do my homework on Unicode. You see, I thought I needed UTF-16 because I thought UTF-8 was too small, but on doing more reading I found very little information regarding programming using UTF-16 or UTF-32 for that matter. Most of what I found was concerning UTF-8. Somehow I finally did more reading on UTF-8 and found out that it covers the whole Unicode character set using a multi-byte sequence to hold characters rather than a single char as in C.
In fact UTF-16 works this way as well, but since it is a larger data type it has to deal with those extra zeros the extra 8 bits bring along. This wouldn't be an issue except for how a computer deals with those zeros, and depending on the processor that you use it can make a big difference. For those familiar with the concept we are talking about big endianess and little endianess. It determines how a computer conceives the value of a sequence of binary digits to put it simply. After reading about the complexities of UTF-16, I decided to do more digging on using UTF-8.
Since UTF-8 could in theory handle all the characters in the Unicode character set only using char, I had to test and see if it worked. So I did a simple test, having it read in characters from Greek, Hebrew, Arabic, Chinese, and to really stress test it all the way past 16 bits of information I used Cuneiform. All of them displayed in the terminal just using normal char functions that are by no means supposed to handle wide characters. Now this approach does have its drawbacks. For starters we cannot index a UTF-8 string the same way we do a normal C string because of the fact it is mulit-byte. To extract a character out of a multi-byte string by array position, you would have to do some extra work. For my program it does not matter as I am not selecting character sequences that way. The other drawback is sometimes the terminal will not display a character high in the range correctly. This has more to do with the font that the terminal is using, but if you were to make a command line application using these high end characters such as the CJK block or Cuneiform, you would need to instruct the user to use the right font or find a way to set that for them. Another disadvantage is until the recent C standard (C11), support for Unicode string literals is not in C. With the new standard it is, but it will be sometime before that feature is supported long enough to use it in production C code.
Using UTF-8 in C is as simple as including the locale.h header and using the setlocale function. Here is an example:
#include <locale.h>
#include <stdio.h>
int main()
{
char buf[300];
FILE *fp;
setlocale(LC_ALL, "en_US.UTF-8");
setlocale(LC_CTYPE, "en_US.UTF-8");
setlocale(LC_MESSAGES, "en_US.UTF-8");
setlocale(LC_NUMERIC, "en_US.UTF-8");
setlocale(LC_COLLATE, "en_US.UTF-8");
fp = fopen("test.txt", "r");
while ((fgets(buf, 300, fp)) != NULL) {
printf("%s", buf);
}
return 0;
}
Using a UTF-8 enabled text editor you can save the language you want to test in there, and then have this code run. You will of course have to do more study for yourself, but hopefully this will give you the start that you need.
Sunday, December 23, 2012
Ellen White Software and Font Troubles
Sometimes in dealing with different computers at the school I will see these hollowed out rectangles in the place of text on the Ellen White software. I have dealt with it a few times and the trouble is the font that the software is looking for is missing. The good news is the fix is simple. What happens at least with Linux (I think I had this problem myself once) and Mac is that Wine will link to where your fonts are at rather than keeping a copy. The trouble is at least with the Macs is that the Arial font which EGW Software is looking for is not in the folder that the Arial.ttf link is pointing to. What I have done to fix it is copy the fonts into Wine's font folder, so I don't have to fix a bunch of symbolic links. You do not have to copy over the symbolic links because the operating system knows the links are not files and treats them differently even if they have the same file name. On a Mac providing you have Office installed the fix looks something like this from the terminal:
Linux users will need to find some source for the Microsoft fonts. Some of us dual boot, so I would encourage copying from your Windows partition to /home/yourusername/.wine/drive_c/windows/fonts, but again if you change where you have your Wine installed you will have to copy to the fonts folder where it is. The other possibility for fonts is through winetricks, but I haven't tried it myself.
cp /Library/Fonts/Microsoft/* /Users/yourusernamehere/Library/Application\ Support/Wine/drive_c/windows/fontsI know I don't have all the details right for the destination folder, but you should have the basic idea. I think under Application Support there should be something called EGW and then a bottle under that, but after that point everything else should be the same. Just look around in the folders. If you find anything post it in a comment please.
Linux users will need to find some source for the Microsoft fonts. Some of us dual boot, so I would encourage copying from your Windows partition to /home/yourusername/.wine/drive_c/windows/fonts, but again if you change where you have your Wine installed you will have to copy to the fonts folder where it is. The other possibility for fonts is through winetricks, but I haven't tried it myself.
Sunday, February 27, 2011
GUIs: Who Needs Them?
In early 2007 I began playing around with the idea of doing everything from the command-line. Not command-line in GNOME mind you, but command-line without X running at all. I switched my computer into init 3 for at least a week, and I was able to do tasks like coding, chatting on MSN messenger, IRC, browsing Wikipedia, watch videos and play audio files all from the terminal without having a graphical session at all. You might be wondering how you can do all of these in a world of only text, but I did it.
Web browsing was the biggest priority for me, and as a result I found a few basic web browsers you could use. They do not load graphical images in themselves so all you do is read text, and page layout is significantly different on some sites. The main program I used is called elinks. It is very simple to use, and pretty straight forward.
For chatting with friends I was able to use a program called centerim. It supports multiple chat protocols such as ICQ, Yahoo!, MSN, AIM, IRC, Gadu-Gadu, and Jabber (which means Google Talk is supported with a little work). At the time I only used MSN and IRC, and for IRC I used another program called irssi instead.
The coolest part was being able to watch videos. The program you use for this is good old mplayer. These days it takes tweaking to get it working in proper order, and I am still trying to figure out how to get audio working on videos under root. When I did it, I was using Fedora Core 6, and all I needed to do was become root, and I had color videos rendered just as well as if not better than on the graphical desktop. I think the reason it doesn't work now is I need to tweak a few things to have root interact with pulseaudio. Mplayer worked much the same way for playing mp3s and other audio files that you would use.
You might wonder what are the advantages to doing things this way. Number one you will save tons on memory and CPU cycles if those are important to you. I could probably slim my memory profile down to less than 256 MB on boot in init 3. The other thing is how cool it looks when all you have is black and white text which only you know how to operate with all the commands unknown to most everyone else. If you have questions about how to get other tasks done on the command-line feel free to leave a question in the comments area.
Web browsing was the biggest priority for me, and as a result I found a few basic web browsers you could use. They do not load graphical images in themselves so all you do is read text, and page layout is significantly different on some sites. The main program I used is called elinks. It is very simple to use, and pretty straight forward.
For chatting with friends I was able to use a program called centerim. It supports multiple chat protocols such as ICQ, Yahoo!, MSN, AIM, IRC, Gadu-Gadu, and Jabber (which means Google Talk is supported with a little work). At the time I only used MSN and IRC, and for IRC I used another program called irssi instead.
The coolest part was being able to watch videos. The program you use for this is good old mplayer. These days it takes tweaking to get it working in proper order, and I am still trying to figure out how to get audio working on videos under root. When I did it, I was using Fedora Core 6, and all I needed to do was become root, and I had color videos rendered just as well as if not better than on the graphical desktop. I think the reason it doesn't work now is I need to tweak a few things to have root interact with pulseaudio. Mplayer worked much the same way for playing mp3s and other audio files that you would use.
You might wonder what are the advantages to doing things this way. Number one you will save tons on memory and CPU cycles if those are important to you. I could probably slim my memory profile down to less than 256 MB on boot in init 3. The other thing is how cool it looks when all you have is black and white text which only you know how to operate with all the commands unknown to most everyone else. If you have questions about how to get other tasks done on the command-line feel free to leave a question in the comments area.
Subscribe to:
Posts (Atom)