Linux in the Classroom: a Look Back
I wanted the grade from the class to reflect two main ideas. The first was learning the material and practicing what we did in lecture. This is where the assignments came into play. The labs and homework always built on what we talked about during our class. In fact, a couple of times I added an idea or two to the assignments that we had not discussed in class. For example, in the assignment above, I did not tell them how to enable quotas for users. The students had to research for themselves how to achieve this task. The next class period I went over the process with them, but I thought it would be nice for them to try solve a new problem on their own.
The second main grading element was practicums. I had these broken up into two days. The first day had two aspects the students had to complete. The first aspect was a troubleshooting practicum. In order to get them ready for this, I had a couple of practice runs that actually were harder than the final practicum. One dry run that was really fun was to stick init 6 into the /etc/rc.d/rc.local file. This usually is the last script run when the system is booted up. The init 6 command tells Linux to go into run level 6, which is a reboot. So, the system would boot up, run all the initialization scripts and then shut them all down and reboot. The students thought they could edit the /etc/inittab file to get back to normal, but that was not the case. They needed a good idea of the boot process to know when the scripts were run to solve the problem quickly. These dry runs were useful in getting them ready for their troubleshooting practicum.
The troubleshooting practicum was a total of six problems, and they had one hour to complete the tasks. A couple of students fixed all six issues, and a couple struggled, but for the most part the students did pretty well on this part. Once time was completed, I went around, graded the lab stations and then proceeded to the second half of the first practicum. The second half was a basic fresh installation of the operating system, Fedora Core 3. The students had 60 minutes to complete this task. Everyone did well on this aspect. This was good, because the workstations we were using also had a Windows XP partition. This should give the students confidence enough to try to install Linux on their own systems, if they desire.
The system administration practicum was fairly straightforward. You probably can imagine some of the tasks, many outlined in the assignment above. The students had to set up accounts, quotas, password expirations, cron jobs, minor security and more. Ten tasks needed to be completed in the required two hours. The trickiest part of this practicum probably was setting up a small RAID. Note that we only had one hard drive, but the skill set is the important issue.
One more component to the grading was a small 5-7 page paper on students' topics of choice, as long as the topics were related to open source. Several interesting ideas were presented, ranging from open-source adoption issues to the current job market to applications needed for the desktop. This assignment was intended to make the students look more deeply into the philosophy and applications of open source.
Here is how grading for the class was structured:
Homeworks and Labs : 50%
Practicum 1 : 20%
Practicum 2 : 20%
Basically, as long as students did their work, they got half of their grade for free. You can see that the paper itself was not a major component of the grading rubric. This means that in order for the students to get a high grade in the class, they needed to do well on the two practicums. In order to insure this, the students needed to know that they must practice their work. The couple of students who took this to heart did well. Other students thought they could cruise through the practicums, but this was not the case. If they had an unlimited amount of time, they might have figured out the problems. However, when you are operating on a fixed amount of time, you really need to know most of the commands off the top of your head. If not, as time flies by, the pressure increases and your performance drops off the table. The old adage really is true in this case--practice makes perfect.
Luckily, a lot of things went really well for us during the semester. Upon reading the student's comments, I discovered that they liked many aspects of the class. First of all, they liked the format. They enjoyed being able to have a lab that reinforced the ideas from the lecture. It was, in a sense, instant gratification in that the students could put the theory into practice right away.
The students also seemed to appreciate the depth we went into about the boot process. They told me that they never really thought about what went on from power-up to login. They now know what the messages actually mean when they are scrolling down the screen. Instead of seeing a lot of "stuff", they now see the grub stages, init starting and all the services that are started on their run level of choice. The words actually mean something to them now, and they can see when an error occurs during the boot process.
Finally, the students enjoyed the practicums. I tried to make them as realistic as possible, and the students seemed grateful. They now are more prepared for the certification process than if they had taken a certification class for the first time. While our practicums were not as tough as a real certification exam, they now know the mindset that is needed in order to have a good chance at succeeding.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SourceClear Open
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Google's SwiftShader Released
- Non-Linux FOSS: Caffeine!
- Parsing an RSS News Feed with a Bash Script
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide