[TUHS] X and NeWS history (long) [ really systemd, student access to real code ]
jon at fourwinds.com
Thu Sep 14 01:42:31 AEST 2017
Arthur Krewat writes:
> For today's kids, well, it's a much different story. My son has a CS
> degree, but has almost no experience really peaking under the hood of
> any OS - some small ventures into kernels, but nothing huge like UNIX.
> Which brings me to another thing. Linux sources are freely available,
> and yet I don't see anyone really looking at them as an educational
> thing. I might be wrong, my experience in higher education is NONE.
I know kids who have poked at this stuff in college. But, it opens a
whole 'nother can of worms.
UNIX was small. One could actually understand it pretty easily.
Linux is huge. I hate to say it, but it's gotten bloated. And it
suffers from a problem with open source. Don't get me wrong, I love
open source, but it's not perfect.
I'm worried that I'm going to come across as flogging my in-process book
too much on this list. Not my intent, it's just that I've already
written stuff that addresses this topic. Here's what I have to say on
it (this part hasn't been attacked by my editor yet).
It's way cool to me that I can run it through nroff and have it work!
A Young Programmer’s Computer Primer
Open Source Software
Open source software is widely successful despite alarmist propaganda
by some established closed‐source companies.1 A main advantage of open
source software is that many more eyeballs are available to look at
the code which translates into benefits such as greater security.
Even if you used a closed source computer system there is a pretty
good chance that you’re still using some open source components.
The development of open source software was greatly enhanced by the
Internet and ‘‘cloud’’ services. It’s trivial to find open source
projects and to start your own. But, and this is a big but, the
majority of open source projects out there are garbage.
A lot of open source software comes from student projects. Since
they’re often first projects, the authors haven’t yet mastered the art
of writing good code. And, much of this software is unfinished as the
student finished their class or graduated or just moved on. It’s
often easier to rewrite something than it is to decipher someone
else’s poorly written and documented code. This is a viscous cycle
because the rewrite often doesn’t get done so there are multiple ver‐
sions which don’t work in different ways.2 It’s often difficult to
determine whether or not there is a good working version of something
because there is so much litter.
There is a belief that one of the advantages of open source software
is that you can fix bugs that you find. Unfortunately, much of this
software is so poorly written and completely undocumented making the
amount of effort required too great for a casual user.
Just because something is open source doesn’t mean that it’s a great
example of the craft. But, you can learn what not to do just as well
as you can learn what to do from looking at other’s code.
There are two indicators, one positive and one negative, that you can
use to help determine the quality of a piece of code.
The positive indicator is whether or not a project is under active
development3 with more than one contributor. It often helps if a
project is supported by some organization. Many of the major open
source projects originated at companies4 who still support their
development. Others have been donated by companies to foundations
that support their development. This often yields a consistent vision
which keeps the project on track. This indicator is not completely
reliable5 so take it with a grain of salt.
The negative indicator is the type and quantity of dialog that you’ll
see at various programmer ‘‘self‐help’’ web sites. If you see lots of
‘‘I can’t figure out how to make this work?’’ and ‘‘Where do I start
to make this change?’’ questions then it’s probably not a great piece
of code. Furthermore, if the responses are mostly useless non‐answers
or snarky and unhelpful then the project probably lacks good develop‐
ers. Developers who blame the questioner for their own lack of qual‐
ity work are not good role models. Of course, it’s also a bad sign if
there are no comments or questions as it means that the code is proba‐
bly not used.
Cautionary tales aside, open source is a great thing. Make your code
open source when it makes sense to do so. But first, learn how to do
a good job so that your code becomes a good example to others.
1 For example, Microsoft claimed that ‘‘Open source is an intel‐
lectual property destroyer. I can’t imagine something that
could be worse than this for the software business and the in‐
tellectual‐property business’’ despite the fact that they were
secretly using open source tools in‐house.
2 I recently needed to extract tags from mp3 files and tried six
different open‐source programs each of which failed in a differ‐
3 This doesn’t apply to projects that have been around for a long
time and are actually ‘‘done’’.
4 One must be careful of open source projects created at companies
who are later acquired by companies with different philosophies.
For example, Sun Microsystems was a prodigious developer of open
source software including OpenOffice, Java, and VirtualBox.
However, Sun was acquired by Oracle who ended support for some
of these projects and tried to find ways to control and monetize
others; see the Oracle versus Google lawsuit for details.
5 For example, the code base for the firefox web browser is a
poorly documented complete mess.
Copyright © 2001‐2017 Jonathan E. Steinhart. All Rights Reserved - Page 2
More information about the TUHS