Introduction
COP-3402
Table of Contents
About me
- Paul Gazzillo
- Associate professor
- Research areas
- Software engineering
- Programming languages
- Security
- https://paulgazzillo.com
Why study systems software?
Know your tools
Newton's Notebook on Grinding Lenses
all technical workers need to be expert at their tools. pilots go to flight school, carpenters may even build their own tools.
when studying optics, newton learned to create his own lenses. here is an image from newton's notebook on grinding lenses.
"A poor workman blames his tools." - proverb
"Tools are made for man, not man for tools." - me (?)
"Technology is made for man, not man for technology" - Aldous Huxley 1961, Thomas Merton 1966
"Don't use your [bare] hands, use a tool!" - my dad
- Need to learn why the tools are useful to be effective
- Don't just use a tool b/c you think it will magically make you do a better job
- Modify your tools! We'll use open-source, configurable tools in this class
Course goal
Learn to use and create systems software
What is systems software?
The bridge between kernel and applications
| Applications |
| Systems software |
| Kernel |
| Hardware |
Debates on what an operating system is
- netscape microsft antitrust lawsuits
- the GNU/Linux stallman argument
- shared history of GNU and Linux
Example systems software
- Libraries: stdio, malloc, etc.
- Programming toolchains: compilers (gcc), linkers (ld), etc.
- Programming environments: building (make), versioning (git), etc.
By the end of the course
Understand the file system
("Where are my files?")
Too many students go through CS without basic understanding of hierarchical file systems.
Modern graphical OSes hide much of it for convenience. But nearly all devices have some sort of file system.
The hierarchical file system was designed by people (you can see an explanation in the reading for next time), so don't take for granted everyone just knows. You need to learn it.
Be conversant in the command-line
The command-line opens you up to the full power of the operating system
You can download and run many more applications that lack a GUI
You can perform powerful automation, for instance, in our lab we script experiments so that others can replicate for themselves our results
The Linux kernel is over 20 million lines of code, has thousands of developers and maintainers and is used in billions of devices
You can develop for it, including submitting patches, entirely on the command-line, and many do
Learn the unix philosophy
Among other things, allows you to build up sophisticated automation from simple tools. There are tons of tools, many of which are standard, that you have access to on a *nix system that make it so you don't have to reinvent the wheel.
Be familiar with GNU/Linux development toolchains
This classic toolchain is used for thousands of software tools: there are well-made tools for writing, building, testing, deploying, and sharing software.
Development can be done entirely on the command-line with this toolchain.
Working with command-line tools shows you the fundamental aspects of software development. If you can master these, you'll only be that much better at the GUIs and IDEs.
Have first-hand experience building systems software, e.g., shells and compilers
Differences from prior courses
Changes from my last offering (2024 Spring -> Fall)
- Course redesign
- Expanded content on core systems software (file systems, command-line, programming environment)
- Broader range of topics
- Easier programming projects, but more of them
- Late project submission still allowed, but only after making a first submission on time
Changes from my last offering (2020 -> 2024 Spring)
- Competency questions for each lecture
- Will have homework questions each week (graded for effort)
- Final will have similar questions
- Staying on topic, fewer tangents, leaving student discussions outside of lectures
- 1hr lectures, 15min of questions, discussion per session
- 2020 offering was quite positive
- two comments for improvements
- i get easily distracted by questions
- specific questions at end of course to focus students on important takeaways
Changes from my last offering (2019 -> 2020)
- More in-class coding and demos
- Lexer/parser given to you
- More breathing room to cover complex topics
- students liked in-class coding, doing more of that
- toy compiler, code together
- submit your copied version
- liked learning systools, particularly git
- need more instruction on using the command-line (since i expect it)
- devoting part of course material to it
- students did not like lack of detail on theoretical concepts
Ulterior educational motive
- Make everyone a better programmer
The tortoise and the hare
The tortoise and the hare are both given a challenging programming project.
The hare immediately starts coding.
After all, finishing the coding is done, so the faster we write code, the faster we finish.
The tortoise starts with comments, planning, and tests before even a single line of code gets written.
The hare finishes coding before the tortoise even starts.
But now the real work begins….
The hare runs a large test given by the professor.
It breaks the program of course.
The hare starts guessing and changing code that might be broken.
But now another test is breaking.
Fixing that bug breaks the first test.
If the hare is lucky, all given tests work eventually.
But the hare is surprised at a bad grade, because new tests written for grading also break.
The tortoise, meanwhile, starts by dividing the problem down into simpler pieces.
He writes some simple examples to illustrate the problem.
He takes an easy piece of the problem and writes comments about what the code should do.
Only then does he code, little by little, testing along the way.
The tortoise makes sure simple things work properly before moving on.
He doesn't take for granted that the code just works.
He knows debugging is really hard, especially when there are lots of bugs together.
This is what the hare found out the hard way when new fixes broke old tests.
The tortoise took way longer to get a line of code written.
But when he got there, the code was much easier to write and write correctly.
- illustration, race track (end goal, correct program)
- hare: coding phase short, debugging and testing very long
- tortoise: planning and testing are long, coding very short, brief new testing
While the hare felt like he was "coding" fast, the tortoise was calmly
- writing tests
- writing comments on what he was doing, and
- writing a few lines of carefully-thought-through code at a time.
When he runs all the tests from the professor, they almost all work.
For the ones that don't, he just isolates the problem with a minimized test.
His code is well-commented, simple, and organized, so he has no issue finding where in the code the problem is and he fixes it.
His grade is good, because even unseen tests are likely to work.
Be the tortoise.
Caveat, there are absolutely times to be the hare. Hacking a simple bash script, getitng something done fast, small programs, inconsequential programs. But really hard problems, getting code correct (so a plane doesn't crash), needs you to be the tortoise.
How to be the tortoise
- Know how your programming language works, don't guess what your program is doing
- Know your programming environment well, develop fast workflows
- Break the problem down before coding, use abstractions (like functions) to organize your code into pieces
- Make sure simple stuff works before moving on
- Write your own tests, and save them (don't overwrite your file, you've lost an opportunity to retest!)
- Develop good debugging skills: minimize the test, identify the bug's location, understand the reason for the bug before trying a fix (just like good coding practices in the first place!)
We'll have lots of opportunities to practice these principles during this class.
Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?
Brian Kernighan, The Elements of Programming Style, 2nd edition, chapter 2
Learning systems programming makes you a better programmer
- Understand how
- programming languages are implemented
- the programming environment works
- theory makes programming easier
Three virtues of a great programmer
https://web.archive.org/web/20211014194234/http://threevirtues.com/
"According to Larry Wall(1), the original author of the Perl programming language, there are three great virtues of a programmer; Laziness, Impatience and Hubris
- Laziness: The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful and document what you wrote so you don't have to answer so many questions about it.
- Impatience: The anger you feel when the computer is being lazy. This makes you write programs that don't just react to your needs, but actually anticipate them. Or at least pretend to.
- Hubris: The quality that makes you write (and maintain) programs that other people won't want to say bad things about."