Alright, time for the book club update - this time from the TTY!

Chapter 15 and 16 were interesting, especially that these chapters start
tackling day to day use and "methodology".


Chapter 15: Tools

In this chapter we put ourselves in the boots of new users, devs,
selecting their toolset to do common tasks on Unix.

Quote:Finding and assembling them into a kit that suits your needs has
traditionally taken considerable effort.

This reminds me of the classic tejr's post: https://blog.sanctum.geek.nz/series/unix-as-ide/

Quote:yacc has a rather ugly interface, through exported global variables
with the name prefix yy_. This is because it predates structs in C;
in fact, yacc predates C itself; the first implementation was written
in C's predecessor B.

I didn't know that.

Quote:In the mid-1980s it was fairly common for large Unix program distributions
to include elaborate custom shellscripts that would probe their
environment and use the information they gathered to construct custom
makefiles. These custom configurators reached absurd sizes.

We still got one of these build.sh for some projects at work.

This makes me realize I've never actually learned any of these
Makefiles generator, I probably should one day. Does anyone have a
recommendation? It seems meson is the way to go today.

On the VCS, that always reminds me of this thread:
https://nixers.net/Thread-Comparing-the-...ol-systems
...And there's no mention of git either.

Chapter 16: Reuse

Philosophy of the rule of least action: don't redo something if someone
has already done it. Unless you want to learn how it was done or if you have
time to waste.

Quote:Newbie is growing horribly frustrated. He had heard in college that
in industry, a hundred lines of finished code a week is considered
good performance. He had laughed then, because he was many times more
productive than that on his class projects and the code he wrote for
fun. Now it's not funny any more. He is wrestling not merely with
his own inexperience but with a cascade of problems created by the
carelessness or incompetence of others problems he can't fix, but
can only work around.

Newbie is learning a lesson; the less he relies on other peoples' code,
the more lines of code he can get written. This lesson feeds his ego. Like
all young programmers, deep down he thinks he is smarter than anyone
else. His experience seems, superficially, to be confirming this. He
begins building his own personal toolkit, one better fitted to his hand.

They have the drives and needs of artists, including the desire to have
an audience.

So true, I find the NIH complex description to be on point. There's a
lot of that, always has been a lot of that.

Quote:People from outside the Unix world (especially non-technical people)
are prone to think open-source (or free) software is necessarily
inferior to the commercial kind, that it's shoddily made and unreliable
and will cause more headaches than it saves.

I think that this mentality is slowly changing in many parts of the world.

Quote:They may lack polish and have documentation that assumes much, but the
vital parts will usually work quite well.

It's also a good omen when the software has its own Web page, on-line
FAQ (Frequently Asked Questions) list, and an associated mailing list
or Usenet newsgroup. These are all signs that a live and substantial
community of interest has grown up around the software. On Web pages,
recent updates and an extensive mirror list are reliable signs of a
project with a vigorous user community. Packages that are duds just don't
get this kind of continuing investment, because they can't reward it.

Documentation is often a more serious issue. Many high-quality open-source
packages are less useful than they technically ought to be because they
are poorly documentated.

We're here to fill the docs!
I agree that the community around a software or framework/library,
users and devs is what shows its alive.

On the "where to look": these days there's github, gitlab and blogs,
and things are easily found on search engines, it's booming.