[TUHS] X and NeWS history (long) [ really systemd, student access to real code ]

Jon Steinhart 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‐
    ent way.

  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 mailing list