[TriLUG] Linux home directory management is about to undergo major change

[Matt Flyer via TriLUG]

Back, oh about 20 years ago, when I first started getting into Linux
(*) one of the first books that I read was one titled "The Art of Unix
Programming".  For those who haven't heard of it, its a tome that goes
into a lot of the philosophical design details of the Unix way,
including things like the importance of keeping things textual, which
is a reference to things like log file format.  The reason being is
that a person is capable of reading and manipulating the text much
easier than they can an encoded binary format, which can make a real
difference in a crunch or after a crash.

That philosophy along with others, such as doing one thing and doing it
well, and planning for your program to receive input from an other and
output to yet another one have served me well during my time as an
(embedded and real time) software developer.  

As a semi modern example of some of this philosophy, at work we have a
SCADA application that sits on top of our control system as a form of
user interface. The SCADA program provides real time data trends that
are stored in a proprietary binary format and consequently they can
only be used with the tools provided by the vendor. The system also has
a historian that is fed from a subset of these trends and they get
stored in a SQL database. Once they're in the database, the data can be
accessed using your language of choice (I've done it in Shell, PHP,
Python, and Ruby). One time we had a request for several years of data
over a large number of variables. To manually get this data using the
vendor supplied tools to retrieve, cut and paste it into an excel file
would have taken several days of man labor.  I was able to write a
script that iterated over these variables to retrieve that data and
post process it in the same manner as the vendors tool.  I then used
the "paste" command to join the list of output files, into a comma
separated table that could be imported into excel - each one containing
roughly 35,000 lines and several dozen columns.

For the first iteration, I probably spent about as much time as I would
have manually retrieving the data. However, a couple of days later,
when I was asked for another years worth of data, I was able to
retrieve it in a manner of seconds simply by adjusting the desired date
range.  As it worked out, I received several requests for more data.

The classic Unix philosophy served me well and saved me A LOT of time
and effort.

* - I remember attending a presentation given by the instructor of my
microelectronics circuits class back sometime in the early 1990s. He
discussed two things that were on the horizon that seemed like science
fiction. One was this new concept called Universal Serial Bus where you
could plug a string of devices together and they would all talk to each
other. The other was about this guy in Finland who had ported the Unix
kernel to the x86 architecture.


On Mon, 2020-05-04 at 11:50 -0400, Wes Garrison via TriLUG wrote:
> Steve and others know a lot more about it than I do, but from my
> limited
> experience one of the frustrations is that systemd replaces
> longstanding
> simple things like discrete log files for services with one
> monolithic log
> file.
> 
> What's worse, the log file is in a *binary* format, so to read the
> log file
> I have to type:
> journalctl -u servicename -n 30
> 
> vs. just being able to:
> tail /var/log/exim4/exim.log
> 
> Not a huge deal, but just one of many examples of simple services
> that are
> all "consumed" by systemd.
> 
> I'm not a power user, so I'm adapting, but I see the frustration.
> 
> -Wes