======Part 2======
=====Entries=====
====October 16, 2011====
* What action or concept of significance, as related to the course, did you experience on this date?
I played with and experienced the C and C++ programming languages.
* Why was this significant?
This is significant as C is important within the UNIX environment.
It was an awesome experience. I learned that I can write a program in C or C++ and execute that
program from a shell script and then further manipulate the data.
====October 19, 2011====
* What action or concept of significance, as related to the course, did you experience on this date?
I got to experience what can happen when you try to alter something and don't properly research it first.
* Why was this significant?
It is an important lesson to learn as in the future I may actually have important things on a system that I have control of
and breaking it would cause actual problems.
* What concepts are you dealing with that may not make perfect sense?
I don't exactly understand what pulgins are or what they do.
* What challenges are you facing with respect to the course?
I don't know how to fix what I did and I think that would be important in the grand scheme of things.
====October 42, 2011====
As an aid, feel free to use the following questions to help you generate content for your entries:
* What action or concept of significance, as related to the course, did you experience on this date?
I played around with the command apt-get install
* Why was this significant?
It is an effective way to acquire things from the great internet via a CLI.
* What concepts are you dealing with that may not make perfect sense?
Everything makes sense with this command
* What challenges are you facing with respect to the course?
It is incredibly annoying to download via apt-get install if you do not know the specific name of the package you want
====October 98271, 2011====
Back in the month of beginning...as it was the beginning month I wish I had known about this
As an aid, feel free to use the following questions to help you generate content for your entries:
* What action or concept of significance, as related to the course, did you experience on this date?
I learned about PINE.
* Why was this significant?
It makes e-mail much easier to access
* What concepts are you dealing with that may not make perfect sense?
Myself as I had know that there is no way e-mail has to be opened the hard way and I could have asked a question anytime
* What challenges are you facing with respect to the course?
I know some things can be done, I think some things can be done, and I assume some things can be done.
=====unix Topics=====
====Wildcards====
Wildcards are used in the manipulation and management of files.
lab46:~$ cd src
lab46:~/src$ gcc -o hello hello.c
lab46:~/src$ ./hello
Hello, World!
lab46:~/src$
====Local Host====
Is the server that you are operating from should you be at that servers location.
For example, working on the lab46 server while in the lair.
lab46:~$ cd src
lab46:~/src$ gcc -o hello hello.c
lab46:~/src$ ./hello
Hello, World!
lab46:~/src$
====Remote Host====
Is the server you are operating from should you not be at that location.
For example working on lab46 from home via putty or or some version of linux.
/*
* Sample code block
*/
#include
int main()
{
return(0);
}
====Shell Scripting====
Is the act of entering command lines into a text editor to be run by the shell when executed.
lab46:~$ cd src
lab46:~/src$ gcc -o hello hello.c
lab46:~/src$ ./hello
Hello, World!
lab46:~/src$
====C====
Is one of the most important programming languages in existence. C is widely used across numerous platforms for an
uncountable number of things.
/*
* Sample code block
*/
#include
int main()
{
return(0);
}
====Current Working Directory====
In a nutshell the directory you are currently working in.
lab46:~$ cd src
lab46:~/src$ gcc -o hello hello.c
lab46:~/src$ ./hello
Hello, World!
lab46:~/src$
====Regular Expressions====
Regular expressions are used for the manipulation of test. They can be used to filter, alter, etc.
/*
* Sample code block
*/
#include
int main()
{
return(0);
}
====X Window System====
Identification and definition of the chosen keyword. Substitute "keyword" with the actual keyword.
If you want to demonstrate something on the command-line, you can do so as follows:
lab46:~$ cd src
lab46:~/src$ gcc -o hello hello.c
lab46:~/src$ ./hello
Hello, World!
lab46:~/src$
====The UNIX Shell====
Identification and definition of the chosen keyword. Substitute "keyword" with the actual keyword.
If you wish to aid your definition with a code sample, you can do so by using a wiki **code** block, an example follows:
/*
* Sample code block
*/
#include
int main()
{
return(0);
}
====Compiler====
Identification and definition of the chosen keyword. Substitute "keyword" with the actual keyword.
If you want to demonstrate something on the command-line, you can do so as follows:
lab46:~$ cd src
lab46:~/src$ gcc -o hello hello.c
lab46:~/src$ ./hello
Hello, World!
lab46:~/src$
====Assembly====
Identification and definition of the chosen keyword. Substitute "keyword" with the actual keyword.
If you wish to aid your definition with a code sample, you can do so by using a wiki **code** block, an example follows:
/*
* Sample code block
*/
#include
int main()
{
return(0);
}
====Removing====
From the file context. Is the removing/deleting of a file. This can be done through the use of rm.
lab46:~$ rm filename
=====unix Objective=====
====Objective====
Exposure to command-line tools and utilities.
===Method===
I will be measuring this objective through my ability to use the CLI.
===Measurement===
Throughout the course I have been becoming more proficient using the CLI. When the course began I didn't know anything, (to the point where I couldn't touch a file) now I can do anything from the CLI that I can do from a GUI. (If I can't I at least know where to look to figure it out)
===Analysis===
Reflect upon your results of the measurement to ascertain your achievement of the particular course objective.
* How did you do?
Fairly well I can work with a CLI infinitely better than when I began.
* Room for improvement?
There are some things that I still have to think about and with Linux systems I would argue that since no one person knows everything there is to know there is always room for improvement.
* Could the measurement process be enhanced to be more effective?
Perhaps with a written test on the use of various commands and tools provided by the CLI. Asking questions like what can you use for arithmetic? and What would you enter to find the answer to 392385 * 239823? (The experiments and projects performed in the course are a far better test than a test could ever be, so if my opinion matters my method of measurement is better.)
* Do you think this enhancement would be efficient to employ?
Yes because with a test of this sort it could be efficiently graded via a shell script, and broken down in a matter of seconds to find out what areas a student may know or may need improvement in.
* Could the course objective be altered to be more applicable? How would you alter it?
Honestly I would leave it as it is.
=====Experiments=====
====Experiment 1====
===Question===
Can I get a three dimensional desktop layout for Ubuntu? (aka really cool looking pimped out desktop)
===Resources===
Download compiz.
===Hypothesis===
I believe that I can figure out how to alter my desktop with the use of compiz with relative ease.
===Experiment===
I am going to run compiz and check boxes that seem like they will do what i am looking for.
===Data===
I checked some boxes that seemed like they would give me the appearance I wanted ("cube") and in order to do this plugins were disabled. I effectively ignored all warnings and proceeded.
===Analysis===
Based on the data collected:
* was your hypothesis correct?
No my hypothesis was dead wrong
* was your hypothesis not applicable?
Perhaps not I really have no understanding as to how compiz works, just what it is supposed to do. I should have looked into it before diving in.
* is there more going on than you originally thought? (shortcomings in hypothesis)
Probably....once again should have gotten a manual.
* what shortcomings might there be in your experiment?
Research...research....research.
* what shortcomings might there be in your data?
I reiterate, research as opposed to the download and click away strategy.
===Conclusions===
I can honestly say that there are some things that shouldn't be attempted without a manual or tutorial. My window manager was messed up beyond repair even before doing my next experiment I was looking into a re-install of Ubuntu.
====Experiment 2====
===Question===
What what will happen if I run sudo rm -rf /?
===Resources===
Among the first things I learned about Linux this is the one command that should never be entered. "Bad" things are supposed to happen.
===Hypothesis===
I believe that sudo rm -rf / will effectively and efficiently shred my file system and make the system unusable within a matter of seconds.
I am under this belief because it should remove nearly all of the files from the system...including the ones that make it work.
===Experiment===
I am going to open up a terminal and type sudo rm -rf /.
===Data===
A bunch of things happened, files were removed, and there were a lot of files that could not be removed. After the command was entered I did an ls expecting nothing to happen and all of the files in my working directory appeared to be there. To be honest I was surprised to find that the system didn't immediately crash.
===Analysis===
Based on the data collected:
* was your hypothesis correct?
No and yes. For some reason it appeared that the rm -rf / initially did nothing. This was incorrect as I couldn't even boot Ubuntu when I attempted after a restart.
* was your hypothesis not applicable?
It was applicable.
* is there more going on than you originally thought? (shortcomings in hypothesis)
If I were to guess there are probably fail safes built into Ubuntu that prevent the absolute nuking of the file system via this command. It may be possible however that the files that were removed were simply not on the surface. I probably should have taken the time to look through the file system in detail to find what was missing. Another "theory" I have is that everything was stored in some form of short term memory and therefore usable until I performed the reboot. (This is however just a theory I will get around to researching it at some point in time.)
* what shortcomings might there be in your experiment?
I don't think there are shortcomings in the experiment, I had root access and entered the command that should not be entered.
* what shortcomings might there be in your data?
I didn't look through the file system in detail after entering the command, doing so may have provided more insight as to what really happened.
===Conclusions===
I can say after this experiment that rm -rf should not be entered as it really will make your system unusable. I was looking for an explosive reaction of sorts and got firecrackers (for those people who appreciate metaphors) the firecrackers did end up burning down the house.
====Retest====
===State Experiment===
I am here today to bash on an experiment performed by Kelly Reed.(More or less prove him wrong because I think he can handle it.) http://lab46.corning-cc.edu/opus/fall2011/kreed11/start#experiment_1. The experiment performed was done in order to test the limit of the numeric value of a variable bash can handle.
====Mo-Betta Experiment====
So originally while retesting Kelly's experiment I did not use the command let. I simply entered a=1 a=11 etc. Doing it this way provided me far more places that bash can handle than 19 (I didn't exactly pay attention to his steps until after I tested it this way.) I got bored of entering a=1111111111111111111111111....etc and echoing it as I continued to get the return value. So to speed this process up I started to echo $a*$a | bc this also continued to give me an accurate return. (bc does however add in the /) After doing this I was thinking Kelly was crazy so I returned to his opus page to find out how he came to the conclusion that he did. Following his steps using let a=1234567890123456789 returned exactly the results he received. So my conclusion is that bash can handle more than 19 digits but let cannot. (I tried to man let and got nothing so I don't know at all what let's issue is, just that it has one)
===Resources===
Evaluate their resources and commentary. Answer the following questions:
* Do you feel the given resources are adequate in providing sufficient background information?
*Yes
* Are there additional resources you've found that you can add to the resources list?
*No
* Does the original experimenter appear to have obtained a necessary fundamental understanding of the concepts leading up to their stated experiment?
* Yes
* If you find a deviation in opinion, state why you think this might exist.
* I am of the belief that bash is capable of far more than 19 digits. (I've seen it....I've seen a lot of things man)
===Hypothesis===
Kelly was of the opinion that bash would handle a number of places (32) or some value divisible by 2.
* Do you feel their hypothesis is adequate in capturing the essence of what they're trying to discover?
* Yes the conclusion was just wrong
* What improvements could you make to their hypothesis, if any?
* None
===Experiment===
Follow the steps given to recreate the original experiment. Answer the following questions:
* Are the instructions correct in successfully achieving the results?
* Yes
* Is there room for improvement in the experiment instructions/description? What suggestions would you make?
* No
* Would you make any alterations to the structure of the experiment to yield better results? What, and why?
* No
===Data===
Following the steps in Kelly's experiment I received exactly the same results.
===Analysis===
Answer the following:
* Does the data seem in-line with the published data from the original author?
* Yes
* Can you explain any deviations?
* No
* How about any sources of error?
* No
* Is the stated hypothesis adequate?
* Kind of
===Conclusions===
Answer the following:
* What conclusions can you make based on performing the experiment?
* Bash can handle more than 19 digits let for whatever reason is the problem
* Do you feel the experiment was adequate in obtaining a further understanding of a concept?
* Yes
* Does the original author appear to have gotten some value out of performing the experiment?
* Yes
* Any suggestions or observations that could improve this particular process (in general, or specifically you, or specifically for the original author).
* Nope