Tennessee Tech University Department of Computer Science Blog

(This post was authored by Dr. Bill Eberle)

So where do I go from here? Different people are telling me different things – you should do this, you should do that – but none of it felt like what I really wanted to do. I wasn’t even sure what school I wanted to attend. (Starting to sound like one of those teenage angst movies from the ’80s and ’90s, or maybe a bit like “The Graduate”, without Mrs. Robinson). When I was a junior and senior in high school, I toyed with a few different majors. Architecture. Journalism. (I thought I wanted to be a sportswriter). I didn’t even decide on what school I was going to (SMU? UH? UT?) until the end of my senior year when I picked the University of Texas (without even a college visit). Now, what was I going to major in? Since I wasn’t sure exactly what I wanted to do, I decided to apply and was accepted into the Honors program – basically an “undecided” major for students who had aspirations of going on to medical or law school (still not sure what I was thinking).

In the second semester of my freshman year, I decided to take an elective: Intro to Programming. I had played with Basic before, but other than the manual that came with Basic (there was no internet back then), it was all “self-taught” – and if I could look back on the code I wrote back then (primarily games), I am sure I would be embarrassed. But even then, I knew I didn’t really know how to program – or even the basics of computer science – so I was kind of excited to see what a programming class would look like.

Back then, the Intro to Programming and the Data Structures and Algorithms – the first two courses in the computer science curriculum – were taught in Pascal. When I look back on Pascal, I realize what a wonderful first programming language! Not one that would ever be used in the real world, but a great way to be introduced to variables, loops, conditional statements, strict type-checking, etc. I remember watching the instructor (there were about 100 of us in the class), writing on those clear plastic sheets that sat on a box containing a bright light that projected the image on the screen, showing us how concepts could be implemented in Pascal. I was ready to start hacking out my first working program – and fortunately, I didn’t have long to wait! Little did I know that it was not as straightforward as simply typing at a keyboard…

So, the way programming worked in the early ’80s (at least for the first year of computer science majors at the University of Texas) was that you wrote your program (i.e., lines of code) on a piece of paper. Then once you felt like you had the correct sequence of code, you went down to the University Bookstore and purchased a stack of punch cards. Don’t know what that is? Think of a paper airline ticket. Wait, don’t know what is either? Think of a time clock at the factory… Oh, never mind. It is a card about the size of a pocket protect… stencil… oh never mind – a long piece of stiff paper. Then you would put each card into what looks like a type-writer. (I am done making analogies). Then, as you typed on the keyboard, the line of code would be punched on the card along with holes that correspond to that line of code. Finally, once all lines of code have put onto separate punch cards, you were ready to get the program compiled and run. Unless you dropped all your cards while walking them to the computer operator… Remember: order of code (or in this case cards) matter.

Fortunately, someone had told me a trick one time to (a) put a rubber band around your cards, and (b) put them in a box. I still remember standing in line at the computer center (after having typed/punched my first program) and handing my stack of cards – rubber-band and all – to the operator. (Who was usually another student at the university). Now, today, we type the compile command with the name of the file (or files) to compile (or use a form of a Makefile) and then run the code getting an answer almost immediately. (In later classes I would learn about linkers and loaders – other topics long since forgotten in computer science education). In those days, you left your “baby” in the hand of someone else. And if you were lucky, you would come back in a few hours to see what happened.

So, now it is after dinner. I return to find on a table to the side a green and white striped stack of paper, with holes along both sides, about the size of a welcome mat (okay, I still had one more analogy), with my name and ID number of the top page. (Which helped when finding which was mine among all of the other freshmen who were working late that day). I pick up my first “job” and proceeded to find an open table where I could review my program and what it produced for results. The first few pages were my lines of code replicated in the order of their cards. Looking good! Then, I would get to the last page. Wait? Where is my output? What is this?

unknown variable – the variable x is not declared

Okay… How late is the computer lab open?

Net Time: Building Flight Simulators

(This post was authored by Md. Ahsan Ayub and Katie Brown)

The Computer Science Graduate Student Club successfully conducted five seminars in the Spring 2021 seminar series. In this edition of the seminar series, the club hosted five Computer Science Master’s students to present their research work, among which four of them are scheduled to graduate this semester. The seminars are open for all students at Tennessee Tech University. Due to the ongoing COVID-19 pandemic, the seminars were streamed via Microsoft Teams.

The club extends their heartiest gratitude to all the speakers as well as participants during the seminars, faculty members to promote their Master’s students and share their expert opinion after each presentation, and faculty advisers and CS staff for their constant support and kind coordination throughout the semester. The details on each seminar are as follows:

Seminar 1: “Cloud Malware Detection using Deep Learning” by Andrew McDole (Advisor: Dr. Maanak Gupta)

Overview of Andrew’s Seminar: As more services move towards cloud environments, the threat of malicious actors injecting malware onto these cloud systems is greater. In response to this threat, malware detection methods must continually evolve to combat increasingly sophisticated malware. Deep learning methods can provide higher accuracies when analyzing low-profile malware in these online cloud-based systems. Link to Watch: https://web.microsoftstream.com/video/5f3cb775-174b-4195-9e68-252a729f9620

Seminar 2: “Insecure Coding Patterns in Julia Projects” by Justin Murphy (Advisor: Dr. Akond Rahman)

Overview of Justin’s Seminar: Julia is an emerging programming language that is designed to provide syntax similar to that of a scripting language, such as Python, and comparable program execution speed with low-level memory access, such as C. Despite reported benefits with respect to productivity, efficiency, and possessing unique properties, Julia programs can include insecure coding patterns (ICPs). ICPs, such as hard-coded passwords, can be used by malicious actors to perform attacks. The goal of the project is to help practitioners avoid insecure coding patterns (ICPs) while developing Julia projects by conducting an empirical study of ICPs in Julia projects. Link to Watch: https://web.microsoftstream.com/video/67096b95-a97c-416c-9c9f-36a030955e5b

Seminar 3: “Scheduling Elastic Message Passing Parallel Application in HPC Environment” by Debolina Halder Lina (Advisor: Dr. Sheikh Ghafoor)

Overview of Debolina’s Seminar: Elastic parallel application that can change the number of processors while running, promises improved application and system performance as well as new classes of parallel applications. From the application point of view users want lower response time and lower turnaround time, on the other hand from the system perspective we want higher utilization and throughput. Elastic application promises both by reducing fragmentation. In addition, elastic applications provide the possibility of predictive proactive fault tolerance via shrinkage in increasingly larger HPC systems where mean time between component failures is decreasing. The research work for elastic parallel systems is at a very early stage and rudimentary at best. The major challenges for elastic parallel sstems to become reality are: 1) lack of programming models for elastic applications, 2) lack of support from message passing libraries and middleware and 3) lack of adequate support from HPC resource management systems. In our research we are developing a model for elastic parallel applications and a model of their interactions with resource management systems. We are also investigating the impact of different scheduling algorithms for elastic parallel applications on system and application performances. Link to Watch: https://web.microsoftstream.com/video/6224d391-639a-4be6-8e21-471c25da06f1

Seminar 4: “Securing Cyber Physical System Networks and Communication” by Trey Burks (Advisor: Dr. Denis Ulybyshev)

Overview of Trey’s Seminar: Many aspects of cyber-physical systems (CPS) and the protocols they use in their networks are not secure. They are typically limited by the age of the protocols or the computation capabilities of the physical devices. This presentation will focus on my research to provide efficient solutions to secure these networks, including moving target defense (MTD), encryption through intermediary devices, and the addition of noise to the communication channels. Link to Watch: https://web.microsoftteams.com/video/d86128d2-bc4e-48b2-9804-6e437ab6682

Seminar 5: “Growing the Science of Validation and Verification for Julia Programs” by Raunak Shakya ( Advisor: Dr. Akond Rahman)

Overview of Raunak’s Seminar: Julia is an emerging programming language that was designed to provide syntax similar to that of scripting languages, such as Python, with similar program execution speed of compiled languages, such as C. Despite reported benefits with respect to productivity and program execution time, Julia programs can include defects that can have serious consequences, for example, producing erroneous scientific results that can potentially misguide scientists. We are conducting our empirical study on two subjects – the first is on the categorization of defects found in open-source Julia programs from GitHub, and the second is on fuzzing the Julia compiler binary to identify latent bugs in the compiler implementation. A taxonomy of defects for Julia programs can help researchers and practitioners understand the nature of defects and provide guidance in prioritizing validation and verification activities in Julia-based software development, and the discovery of previously unknown bugs in the Julia compiler will help the concerned developers to fix them, thus increasing the compiler’s performance and reliability. Link to Watch: https://web.microsoftstream.com/video/01fb928d-2837-431e-8750-d1922d352bf4

(This post was authored by Cyril Focht)

When we look at software—and think about the process of creating software—it’s easy to assume that software is neutral: politically neutral, ideologically neutral and values neutral. Software is mere calculation, after all, and how could the numbers that comprise those calculations be anything but neutral? Because this is such a natural line of thinking, we as engineers and as creators of software, often aren’t cognizant of the ways in which we need to be critical of that software. Software may be a series of calculations, but it is human motivated: implemented by humans and used by humans. It’s in those human motivations that values and ideology emerge.

There are probably as many different ways to understand these ideologies as there are ideologies themselves, but in this blog post I’ll demonstrate two perspectives we can use to understand how that ideology comes into play: software as a model, and software as a tool. A model in the sense of a scientific model, like any number of equations used in physics or a scale model in architecture, and a tool in the sense of, well… a screwdriver or a hammer.

Starting with models—which are representations of human understanding of the world around us. All software is built on a model in some way, from a model of satellites’ orbital trajectories in GPS systems to conversions between Fahrenheit and Celsius that we’ve used in our first programming class (arithmetic itself is a model). Again, it’s easy to get caught in the thinking that the world around us is and therefore the way we understand it is neutral, but the way we represent that understanding is a decision. Considering two programmatic functions that calculate the Fibonacci sequence, one iterative and one recursive, those two functions are two fundamentally different ways of understanding and representing the same phenomenon. As someone with a lot of pride in my French heritage, I really like to use the adoption of the metric system to demonstrate how this affects us in practice. We’ll have to delve into some of the history of the metric system to see how it was influenced by human values.

The metric system was part of the first piece of legislation passed by the new government following the French revolution. Now, why would a system of measurement have been so important to be one of their first decisions following one of the most violent revolutions in human history? It wasn’t because they thought science was really neat. The short-short version is that before the revolution, France had common units of measurement, but to say they were inconsistent would be putting it lightly. Something that would often happen is that the measures being used by tax collectors weren’t accurate to what was owed, so if I owed some weight of wheat they would use a heavier weight on their scale. They would skim the difference off the top and keep it for themselves, and if they were challenged they had the legal authority to say” no, my measure is correct, this is what you owe.” By creating a more consistent, accessible system, it gave common people the ability to challenge their tax collectors by saying “I don’t think your measure is a kilo, like you say it is, so I’m going to measure a liter of water and compare that to your measure,” and if they don’t match, the tax collector isn’t able to skim off the top. Since this adoption by the French government was deeply intertwined with the very invention of the metric system, we see that its core values as a system of measurement are pushing back against exploitation and holding those in power accountable.

Considering software instead as a tool, I’m sure is how most of us who work in computing are already used to thinking about software, so I won’t dwell on demonstrating why that perspective is a useful one. To compare software again with an entity outside computing, let’s consider a firearm. Before I’ve done any more than invoke the topic, I’m sure you’ve already considered a handful of different ways I might approach this discussion, and many more political positions you’ve seen people take up in public discourse. That in itself demonstrates how our tools carry ideology better than any specific analysis I have to offer, but I will still offer some ways we can consider ideology when thinking about our tools. The most obvious questions are in regards to the tool’s intended use: what is the goal it helps to achieve, how does it help do so, and why is that goal of value? Sometimes the intended use on the part of a creator differs from its use in practice once it’s in the hands of others. Maybe less obvious—but nonetheless most of why people have such strong emotions about firearms as a topic—are the cultural context in which that tool exists, and how the tool affects that cultural context. Consider the cloth facemask, which existed in a drastically different context a year ago than it does now, and as such any analysis, we conduct on such a facemask as an artifact will have changed just as dramatically in that year.

These are all the kinds of things we should be mindful and critical of when we’re creating software. This applies, of course, to those hotly discussed in public discourse, such as social media, autonomous vehicles, AI and machine learning, automation, and surveillance technology, but it’s equally true for those that seem more mundane, like banking and tax filing software, word processors and spreadsheets, mailing systems, or OS kernels. Everything we make requires a series of decisions, and every one of those decisions reflects our values as designers.