Colin McManus SPO600

     In this lab I investigated the transformation of my code from source C code to C compiler output to learn exactly what the compiler is doing when I call it. My initial program was a simple Hello World program: #include <stdio> int main(){         printf("Hello World!"); }      My first compilation was a simple gcc with most of the optimization and fancy tricks stripped out. This was done with the -O0 and -fno-builtin flags, -O0 meaning do not use any optimizations when compiling and -fno-builtin meaning do use any built in function optimizations. So : gcc -g -O0 -fno-builtin -o hello1 hello.c.       The compiler then returns an Executable and Linkable Format file (ELF for short) named hello1 which I used to examine what it had done to my code. The first thing I noticed after using objdump to look at the assembly code that was output was that my simple four line program had ballooned out to 199 lines which led me to wonder how much bigger my elf fi

      For part B of Lab 2 I was tasked with building my own version of glibc and then introducing a bug into it to ensure I am using my build instead of the installed version. Glibc is GNU's implementation on the standard C Library which underpins many functions of the Linux kernel, so it is very important that my build and tests don't affect the systems version of glibc or my classmates will not be happy with me.      The first step is to get the source code for glibc. Since I used wget and tar for part A, I will use git this time to get a feel for both methods. So running git clone git://sourceware.org/git/glibc.git  gave me the source code to build from but before I did there is an important step for glibc which is to create a separate directory to build in as glibc uses two parallel trees for source and build codes. This is nice so that if I have messed up my build I can just clear out that directory and still have the source code to start my build again without having to

     Today I will be building the open source GNU package less. Less is a really handy tool for file reading that lets you traverse backwards as well as forwards through the file. Unlike it's cousin more, less does not have to read the entirety of a file before starting so its great for quickly accessing large files.      The first step is to get the code for it on the server. I am building on AArchie so I will use wget to download the tar file (http://ftp.gnu.org/gnu/less/less-530.tar.gz):      Now I have the compressed tar file a simple tar -xzf less-530.tar.gz  command (-x for extract, -z for decompression with gzip, -f since we are decompressing a file) will unpack it so I can begin my build. I now have a less-530 directory in my working directory and once I move into it I can see the guts of the less package:      The safest choice from here to ensure I don't break my build is to check the README file to see if there are any set up instructions to follow. I w

     While most people today have at least heard of Open Source software, many people, myself included, don't know a lot about how the development process works or how these communities are structured and managed. Today's post will explore these topics in reference to two Open Source projects from different licences, Privacy Badger under the GNU General Public License and Deeplearning4j under the Apache2.0 License. Privacy Badger:      Privacy Badger is a browser extension aimed at striking a balance between a user's right to privacy and content providers' business interest. By only blocking ads and cookies that ignore the Do Not Track setting of the user's browser, thus as long as a content provider isn't hosting those types of ads they won't lose out on ad revenues.      Privacy Badger is run primarily off of its GitHub repository (link below) and it seeks to make contribution easy by keeping a list of desired issues to tackle that are publicly avail