Air Date:
Latest update:
'[1852] In the regiment there was a Lieutenant Slaughter who was
very liable to sea-sickness. It almost made him sick to see the wave
of a table-cloth when the servants were spreading it.
'Soon after his graduation, Slaughter was ordered to California and
took passage by a sailing vessel going around Cape Horn. The vessel
was seven months making the voyage, and Slaughter was sick every
moment of the time, never more so than while lying at anchor after
reaching his place of destination.
'On landing in California he found orders which had come by the
Isthmus, notifying him of a mistake in his assignment; he should
have been ordered to the northern lakes. He started back by the
Isthmus route and was sick all the way. But when he arrived at the
East he was again ordered to California, this time definitely, and
at this date was making his third trip. He was as sick as ever, and
had been so for more than a month while lying at anchor in the bay.
'I remember him well, seated with his elbows on the table in front
of him, his chin between his hands, and looking the picture of
despair. At last he broke out, "I wish I had taken my father's
advice; he wanted me to go into the navy; if I had done so, I should
not have had to go to sea so much." Poor Slaughter! it was his last
sea voyage. He was killed by Indians in Oregon.'
(From Personal Memoirs of U.S. Grant, Ch. XIV by Ulysses S. Grant.)
Tags: quote, usa
Authors: ag
Air Date:
Latest update:
How to annoy folks who use busybox:
$ touch `printf "\033[1;33m\033[44mhello"`
$ ls
''$'\033''[1;33m'$'\033''[44mhello'
$ tar cf 1.tar *hello
$ busybox tar tf 1.tar
hello
$ rpm -q busybox
busybox-1.36.1-8.fc41.x86_64
$
Oopsie-daisy.
A simple ls|cat or ls|less -r produces the same effect.
This won't work with gnu tar & bsdtar, for they both properly escape
escape sequences.
Tags: ойті
Authors: ag
Air Date:
Latest update:
This is the guy who wrote SCCS while working at Bell Labs.
Date: Wed, 3 Jul 2024 17:29:26 -0600
From: Marc Rochkind <mrochkind@gmail.com>
Newsgroups: gmane.org.unix-heritage.general
Subject: Re: Anyone ever heard of teaching a case study of Initial Unix?
Message-ID: <CAOkr1zXSefHKOqTCaGE7Zb_T09HD-s2pM9QfTW8PuMkLGioDGg@mail.gmail.com>
On Wed, Jul 3, 2024 at 9:27 AM Vincenzo Nicosia wrote:
> The programmers considered as "fungible workforce" by mainstream
> software engineering and project management theories are *paid* to
> to their programming job, and they mostly have to carry that job
> over working on prescribed objectives and timelines which have been
> decided by somebody else, managers who know nothing at all about
> software development. Personal interest in the project, passion,
> motivation, curiosity, creative power, sense of beauty, the joy of
> belonging to a community of likeminded people, are never part of the
> equation, at any point.
What a cynical take on software development! The logical error is to
assume that if something is sometimes true (e.g., "managers who know
nothing at all about software development") then it is always true.
My experience over many decades is quite different. Most often,
managers know software quite well. Where they fail is in their very
poor understanding of how to manage people.
The bias that operates in software development, and perhaps all
organizations, is that when there is a disagreement between management
and non-management (e.g., programmers), the non-managers usually
assume that they are always right and the managers are wrong.
I have never met a programmer or group of programmers who were always
right. Most often, they are ignorant of financing, regulatory
constraints, product schedules, commitments, staffing issues, and
everything else that isn't coding. (There are exceptions, but they are
uncommon.) Management, by definition, is the art and science of using
resources to reach an objective. Programmers generally are concerned
only with themselves as a resource and with their own personal
programming objective. It is unusual to find a programmer who
understands management.
Tags: quote
Authors: ag
Air Date:
Latest update:
While reading about Poettering's adventures in determining the best
$TERM value for serial & VM terminals in systemd, I accidentally
discovered that ls from coreutils doesn't consult terminfo to check
whether a terminal emulator (TE) supports colour.
What does it consult then? $TERM? Yes and no.
At first glance, with --color=auto flag, it ignores $TERM
completely, trusting the LS_COLORS environment variable. But if
$LS_COLORS is absent, it still prints in colour for some
terminals--yet, simultaneously, not for all file types. What is going
on?
You may have seen /etc/DIR_COLORS file. Usually, your distro
includes some default sh scripts that invoke the dircolors(1) program
with that file as an argument, generating a big, ugly looking string
value for $LS_COLORS.
The interesting thing about /etc/DIR_COLORS is that it's just a copy
of a file embedded into ls and dircolors programs (as a single
static char const G_line[] variable) during compilation, meaning
that in the absence of /etc/DIR_COLORS they technically still have a
default colour scheme.
ls doesn't read that (probably modified by a user) file directly--it
reads LS_COLORS environment variable, presumably because, in 1996,
dynamically generating $LS_COLORS values was considered too
costly. Hence, ls has a separate table (color_indicator[], for the
curious) listing "important" file types. That table is consulted in
case $LS_COLORS is unset.
But that doesn't explain why with no $LS_COLORS in sight, ls
suddenly starts looking at $TERM. The DIR_COLORS file also contains
a list of TEs ls considers capable of printing in colour. So why,
then, is vt100 on that list when, according to the interwebs, nobody
in 1978 in their right mind thought a colour terminal made any sense,
unless they were driving a Lamborghini Countach? (I might be
exaggerating a little.)
Anyhow, ls employs its embedded DIR_COLORS file to:
/* Check if the content of TERM is a valid name in dircolors. */
static bool known_term_type(void) {
char const *term = getenv("TERM");
if (!term || !*term)
return false;
char const *line = G_line;
while (line - G_line < sizeof(G_line)) {
if (STRNCMP_LIT(line, "TERM ") == 0) {
if (fnmatch(line + 5, term, 0) == 0)
return true;
}
line += strlen(line) + 1;
}
return false;
}
See? Now it's all come together. Moreover, to please
Lennart, in the
next release of coreutils, vt220 will be joining the illustrious crew
of colour terminals too. What a time to be alive.
Tags: ойті
Authors: ag