Hello, and welcome back to CS615 System
Administration!  This is week 4, and after we've
covered storage models and disks as well as the boot
process, partitions, and the Unix filesystem, we'll
spend a fair chunk of the videos for this week on the
topic of software and, more specifically, how to
install it, and how to manage it.

In our last video, we already talked a bit about the
filesystem hierarchy and look at the 'hier(7)' manual
page, and we found out that there is a reason for why
we have a certain directory structure, which tells us
which software parts go where.

This will be something we will get back to when we
talk about package management and software
installation in particular.

In its most general definition, "software" is just
another term for a program telling a computer to
perform a certain task. Practically, however, there
are a number of different types of software, and we've
already seen some of them as part of our discussion of
booting a system.

In this video, we will attempt to categorize these
types, even though the distinctions or differentiating
factors are far from clear-cut as you will quickly
notice.

We have already identified a specific component that
happens to be implemented in software: the file
system.

Instinctively, we categorize the file system as being
in a lower layer than certain applications, such as a
web server for example.

But the file system is only one component of the
operating system, which in turn comprises regular
application software (such as a text editor or a
compiler), software libraries used by many of these
applications (such as the resolver library, used to
turn hostnames into IP addresses), device drivers
providing access to and control of certain hardware
components, and the most central component of the OS
itself, the kernel.

Looking at software from this perspective quickly
makes it clear that the term "operating system" itself
requires some definition, as different OS providers
include different components under this umbrella term.

But before we attempt to tackle the question of what,
exactly, defines an operating system, let us take a
step back and attempt to better categorize software
based on its proximity to the hardware or the end
user.

And what better way to do that than to compare
software or the operating system to

...a car.

People always like to compare other things to cars,
for some reason.

I suspect this is because we all see cars all the time
and thus believe that everybody understands how cars
work.  But alright, so let's try and roll with this...

When we boot up a system, we've seen that before our
operating system is up and running a bunch of things
happen on a lower layer.

So we clumsily represent this part here via this
diagram of the ignition system.  The analogous element
in the world of computers might then be

firmware.

That is, the bits of software executing early on when
we power on our system would fall into this category.

But firmware is even more wide spread and covers

...for example, 

the software running on your wifi access point.

Now this illustrates that it's quite difficult to
properly categorize software:  we know that a switch
or router runs a full operating system, albeit a
specialized one; and many of the consumer products do
as well, frequently customized versions of, for
example, Linux.

But since we often have no way of updating or managing
the software, we consider it to be not quite so soft,
and so we group this under "firmware" as well.

Other devices that may be running some sort of
firmware include things like

remote controls, which nowadays can be of surprising
complexity, or

say, your car's infotainment and navigation system.

Again, these days your car is more likely to run a
full-fledged operating system here, but as a user, it
remains largely opaque to us.

Perhaps a bit lower level, but something we've also
mentioned before includes

the electronics embedded in an IDE drive, or

really anything using USB.

And as we also mentioned earlier, the fact that all
these things are running some sort of software --
firmware -- means that they can be manipulated or
compromised.

Now back to our server systems, the system BIOS
certainly qualifies as a type of firmware, as it is
embedded in the read-only memory, but can be updated
via special tools flashing the ROM, for example.

Similarly, different persistent memory modules such as
NVRAM as shown here by example of an old Sparc station
that then also functions as a first stage boot loader.

As we can see,

there are ways to change the state of the system here
in an interactive way.

As a boot loader, it then eventually hands control off

to the kernel.

Now back to our terrible car analogy, what would we
say represents the kernel?

Well, perhaps we can think of the kernel as the motor:
without it, your car is pretty useless, but similarly,
if all you have is a kernel... well, then you aren't
going to get anywhere, either.

This, by the way, is why -- as annoying as it may be
-- it actually _is_ technically correct (the best kind
of correct!) to insist on saying "the OS is called
GNU/Linux".

But we don't have to be pedantic.

Anyway, so our kernel is a piece of software.  As you
may know, there are different types of OS kernels:
microkernels as well as monolithic kernels.  The
latter are the common kernels you'll find in the Unix
systems we're looking at in this class.

And so we've already seen a way to visualize what the
kernel does: by looking at the boot messages, we see
that it manages the hardware, manages memory and
process scheduling, and provides the system calls for
the regular userland libraries to interact with.

But again, just like a motor all by itself, so is a
kernel all by itself of limited use.  What we need to
build a more useful environment in which we can build
our services is...

...the core operating system.

That is, all the bits and pieces that are not running
in kernel space, but that are necessary for the system
to become useful, usable.

The operating system needs to be tightly integrated
with the kernel -- you can't just take a motor and
plunk it into any chassis and think it'll work; you
need compatible parts and connectors that fit.

Likewise, the kernel is not independent from the rest
of the system.  And this is where things get a bit
hairy: you all know that there exist many Unix
versions, but those all remain their own, coherent
operating systems.

But with Linux, for example, we have many different
variations of combining the Linux kernel with certain
tools -- many of which are the same or similar across
distributions -- to build an OS _variation_.

Some distributions use the init(8) startup system,
others use systemd(8), for example; some ship with
version X of library Y, others with version X + 1.

So you have core libraries that need to hook into the
kernel and that really aren't completely independent
of it, but on top of that, you also have

a number of system components that specifically define
how your operating system behaves and how users
interact with it.

You get additional functionality, but a lot of the
functionality is quite involved in how to operate the
system, how to interact with it, how to change
settings

For us, perhaps the equivalent here is "System
Software", core components of the OS as well as the
bits that influence their behavior, the configuration
files and the like.

Again, all of these are tied primarily to the
operating of the system itself, and so most of the
time people have a need to

extend the system, to add customizations, to buy some
add-ons.

In the software world, the equivalent to these sexy
fuzzy wheel cover and pimped out seats, we might
consider

as add ons things like

a web server,

a database,

an additional programming language interpreter with
its libraries

a language platform and virtual machine

a
calendar-mail-system-editor-ide-kitchen-sink-a-matron

or a revision control system that nobody knows how it
works.


Now you are probably wondering: "hey, wait a second,
my OS comes with all of those out of the box, those
aren't add-on packages or customizations!", but
therein lies a dilemma and a larger discussion we'll
go into in our next video:  deciding what software
components are parts of the OS, what is strictly
speaking an add-on, what is core system software, and
what is optional pink fuzzy frills.

But besides the categories we've so far identified --
firmware, kernel, operating system, system software,
and add-on applications -- we also increasingly have
to deal with systems that fall in between

since nowadays just about every device that you can
plug into a power outlet comes with a full-fledged,
insecure configured operating system running a web
server that you can't turn off.

And even though we may not always think about these
devices and focus on server environments, it's useful
to remember that the same principles do apply when
managing embedded devices and non-compute resources
brought into your network.

What's more, all these separations of types of
software fall further apart as we move into the area
of virtualization, containers, and, say, unikernels.

Is a static, immutable container an instance of an
operating system, or is it more akin to firmware or a
closed-system appliance?

Does the hypervisor in a virtualized environment count
as a proper operating system?  And where do individual
applications running inside containers on a unikernel
fall?

Well, I'm afraid I don't have answers for you other
than "it depends" and "it gets messy real quick".

But hey, welcome to the wonderful world of system
administration!

As I said, we'll try to bring a little bit more
clarity to some of this in the coming videos, when we
talk about software bundling and installation and the
separation of system software from the OS.

But first, let's try to summarize what we covered
today:

First of all -- and I hope this much should be very
clear -- software really is not at all like a car.
Car analogies are almost always pretty awful.

Next, and even though this _sounds_ obvious, we
sometimes forget: all of this software we're talking
about... is indeed software.  That is, it's flexible,
can be changed, can be configured, can be compromised.

That is, many of the principles we'll apply when we
talk about package management, software updates, or
security principles in the coming videos all apply
more or less equally to firmware as to the base OS as
to add-on software.

And so these are really the three broad groups we tend
to divide software in:

the low-level firmware, by which we often mean
software that we generally do not change, that sits
very close to the hardware, and that may be
proprietary or require special tools to interface
with;

the core Operating System, although we've already
gotten a taste that it's not really a very clear-cut
definition, no obvious line that separates add-on
software from system software;

but we do determine that there's _some_ software that
we consider to not be part of the operating system and
that we would need to add after OS installation, for
example.

But with these categories, we then

immediately get to these questions: what, really, is
the main difference?  Is there one, perhaps when it
comes to how we manage the software?

And what about all these other in-between things we
mentioned, all the terrible internet-of-broken-things?
What about network gear, storage equipment, or special
purpose hardware --  such as an HSM -- or third-party
appliances?

Well, perhaps this video here has really only lead us
to more questions than answers, but it's probably a
good idea for you to start thinking in these terms
before we move on to software package management in
our next video.

So as a look back as well as in preparation for that
topic,

you should perhaps go back to the different boot
sequences you looked at from last week, and try to
identify the different types of software you
encountered and how they interact with one another.

Then, think about what the impact is of trying to
update each one:  is that a straight-forward thing?
Can you make a change to one without the other?  What
things do you have to consider when you do that?

Answers to some of these questions will be given in
our next video, so until the next time, and thanks for
watching.  Cheers!