From: Steffen Nurpmeso <steffen@sdaoden.eu>
To: Rik Farrow <rik@rikfarrow.com>
Cc: tuhs@tuhs.org, bakul@iitbombay.org
Subject: [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum)
Date: Wed, 02 Oct 2024 02:55:58 +0200 [thread overview]
Message-ID: <20241002005558.TiqDHtEk@steffen%sdaoden.eu> (raw)
In-Reply-To: <CACY3YMGcSm+ATwbz1TmKKoOQeKCPsoTnT4u93vFdKpZyyHCZ7A@mail.gmail.com>
Rik Farrow wrote in
<CACY3YMGcSm+ATwbz1TmKKoOQeKCPsoTnT4u93vFdKpZyyHCZ7A@mail.gmail.com>:
|On Tue, Oct 1, 2024 at 12:07 PM <arnold@skeeve.com> wrote:
|> Bakul Shah via TUHS <tuhs@tuhs.org> wrote:
...
|>> Sounds like boomer mentality... Kids these days... :-) Also sounds like
|>> the kind of arguments assembly language programmers presented when *we*
|>> were the "kids" trying out "structured programming"!
|>
|> It's not that they're intrinsically unqualified. They were never
|> taught, so they don't know what they're doing. I'm unqualified to
|> fly a plane because I never learned or practiced, not because I'm not
|> intelligent enough. Same thing for many of today's programmers
|> and C / C++.
|And my comment about seeing code produced by programmers while doing sales
|support dates from 1990. This isn't something new, from my perspective. I
|was working in a small programming shop where there were a handful of
|excellent programmers, and then sent out to help customers get started
|using their libraries. That's when I experienced seeing things that still
|make me cringe.
Btw the "official Linux firmware"
https://git.kernel.org/?p=linux/kernel/git/firmware/linux-firmware.git;a=summary
introduced a dependency for the "rdfind" utility i think ~two
years ago (it was later made optional) for this code:
$verbose "Finding duplicate files"
rdfind -makesymlinks true -makeresultsfile false "$destdir" >/dev/null
find "$destdir" -type l | while read -r l; do
target="$(realpath "$l")"
$verbose "Correcting path for $l"
ln -fs "$(realpath --relative-to="$(dirname "$(realpath -s "$l")")" "$target")" "$l"
done
I proposed (because it really drove me mad, i have nothing to do
with Linux kernel stuff etc shall you think that)
(
cd "$destdir" && find . -type f | xargs cksum | sort | {
ls= lf=
while read s1 s2 f; do
s="$s1 $s2"
#$verbose $s $f
if [ "$s" = "$ls" ] && cmp "$lf" "$f"; then
$verbose 'duplicate '"${lf##*/}" "${f#./*}"
rm -f "$f"
#ln -s "${lf#./*}" "${f#./*}"
ln -s "${lf##*/}" "${f#./*}"
else
ls=$s
lf=$f
fi
done
}
)
(as a draft, with only light testing, but it is not far from doing
it at maximum) which only uses POSIX default tools etc, but these
guys from very big companies (RedHat; the guy who did *that* is
from AMD) did not even respond, at least to that.
(At times i tried to get rid of rsync dependency of kernel
makefile officially, as that can also be done via plain shell
tools, they at least answered "what is wrong with rsync".)
Maybe because the patch also included
- compress="zstd --compress --quiet --stdout"
+ compress="zstd -T0 --ultra -22 --compress --quiet --stdout"
but that only brought the firmware into line with the normal Linux
kernel make zstd usage. I will never know.
I think what i am trying to say is that maybe "time is money" in
addition to anything else. (I never heard about rdfind though.
Btw its manual (it has one!) says
SEE ALSO
md5sum, sha1sum, find, symlinks
were cksum is a standard tool. So it is. Everyone its own
infrastructure, how large it is; you all only get the binary
updates anyway, my Linux distribution compiles from source; and
what the mesa library alone has grown in new dependencies that are
mostly never needed let alone at runtime, like YAML, that has been
done at release-tarball-creation time in the past. At least
here.)
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
next prev parent reply other threads:[~2024-10-02 0:56 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-28 13:34 Douglas McIlroy
2024-09-28 16:58 ` G. Branden Robinson
2024-09-28 17:47 ` Luther Johnson
2024-09-28 17:52 ` Luther Johnson
2024-09-28 18:46 ` G. Branden Robinson
2024-09-28 22:08 ` Luther Johnson
2024-09-28 22:45 ` Luther Johnson
2024-09-28 22:50 ` Luther Johnson
2024-09-28 17:59 ` Bakul Shah via TUHS
2024-09-28 22:07 ` Douglas McIlroy
2024-09-28 23:05 ` Rob Pike
2024-09-28 23:30 ` Warner Losh
2024-09-29 10:06 ` Ralph Corderoy
2024-09-29 12:25 ` Warner Losh
2024-09-29 15:17 ` Ralph Corderoy
2024-09-30 12:15 ` Dan Cross
2024-09-28 18:01 ` G. Branden Robinson
2024-10-01 13:13 ` arnold
2024-10-01 13:32 ` Larry McVoy
2024-10-01 13:47 ` arnold
2024-10-01 14:01 ` Larry McVoy
2024-10-01 14:18 ` arnold
2024-10-01 14:25 ` Luther Johnson
2024-10-01 14:56 ` Dan Cross
2024-10-01 15:08 ` Stuff Received
2024-10-01 15:20 ` Larry McVoy
2024-10-01 15:38 ` Peter Weinberger (温博格) via TUHS
2024-10-01 15:50 ` ron minnich
2024-10-01 19:04 ` arnold
2024-10-01 16:49 ` Paul Winalski
2024-10-01 15:44 ` Bakul Shah via TUHS
2024-10-01 19:07 ` arnold
2024-10-01 20:34 ` Rik Farrow
2024-10-02 0:55 ` Steffen Nurpmeso [this message]
2024-10-02 5:49 ` arnold
2024-10-02 20:42 ` Dan Cross
2024-10-02 21:54 ` Marc Donner
2024-10-05 17:45 ` arnold
2024-10-06 12:20 ` Dan Cross
2024-10-06 12:29 ` [TUHS] UREP code (was Re: Re: Minimum Array Sizes in 16 bit C (was Maximum)) arnold
2024-10-01 16:40 ` [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum) Paul Winalski
2024-09-28 18:05 ` Larry McVoy
2024-09-30 15:49 ` Paul Winalski
2024-09-29 16:56 Douglas McIlroy
2024-09-29 20:29 ` Rob Pike
2024-09-29 21:13 ` Rik Farrow
2024-09-29 22:21 ` Rich Salz
2024-09-29 23:56 ` Rob Pike
2024-09-30 0:36 ` Larry McVoy
2024-09-30 0:55 ` Larry McVoy
2024-09-30 1:09 ` Luther Johnson
2024-09-30 1:37 ` Luther Johnson
2024-09-30 3:52 ` ron minnich
2024-10-01 12:43 ` arnold
2024-09-30 19:12 ` Steffen Nurpmeso
2024-09-30 20:03 ` Rich Salz
2024-09-30 21:15 ` Steffen Nurpmeso
2024-09-30 22:14 ` Bakul Shah via TUHS
2024-10-01 1:42 ` Alexis
2024-09-30 20:14 ` Rik Farrow
2024-09-30 22:00 ` Steffen Nurpmeso
2024-10-01 12:53 ` Dan Cross
2024-11-18 12:00 ` Anton Shepelev
2024-11-18 12:46 ` Luther Johnson
2024-11-18 14:05 ` Steve Nickolas
2024-11-18 15:00 ` Anton Shepelev
2024-11-23 22:29 ` Alexander Schreiber
2024-11-18 14:55 ` Anton Shepelev
2024-11-18 16:52 ` G. Branden Robinson
2024-11-18 17:00 ` Anton Shepelev
2024-11-18 18:56 ` Luther Johnson
2024-11-22 1:53 ` Dan Cross
2024-11-22 2:55 ` Luther Johnson
2024-09-29 21:24 ` Ralph Corderoy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241002005558.TiqDHtEk@steffen%sdaoden.eu \
--to=steffen@sdaoden.eu \
--cc=bakul@iitbombay.org \
--cc=rik@rikfarrow.com \
--cc=tuhs@tuhs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).