[sf-lug] Was: JD's Math programs, now SF-LUG Mtg
Michael Paoli
Michael.Paoli at cal.berkeley.edu
Tue Dec 5 02:01:18 PST 2023
--> on-list
On 2023-12-04 21:35, aaronco36 wrote:
> From: "aaronco36" <aaronco36 at sdf.org>
> To: bliss-sf4ever at dslextreme.com
> Cc: Michael.Paoli at cal.berkeley.edu, aaronco36 at sdf.org
> Subject: Was: JD's Math programs, now SF-LUG Mtg
> Date: Tue, 5 Dec 2023 05:35:15 -0000
>
> Am forwarding this to Michael P in order that 1) he could help correct
> my
>
> Was one of those concerns Michael may have brought up during/after the
> meeting regarding filesystem corruption that might have possibly
> adversely
> affected SF-LUG's linuxmafia.com mail-server 'guido', possibly
> resulting
> in having to temorarily disable the SF-LUG mailing-list ?? 8-O
I did mention some more newly discovered filesystem corruption on guido.
Thus far no known impacts to linuxmafia.com - which hosts SF-LUG's list.
http://linuxmafia.com/pipermail/conspire/2023-December/012541.html
< As far as I'm aware, no issues with linuxmafia(.com)
< and its data (other than the occasional kernel Oops)
< and it still continues to be up and running thus far.
> My limited understanding is that Rick M, the linuxmafia.com
> mailing-list
He does graciously host the list on linuxmafia.com.
Current list admin(s) can be seen, e.g. here:
http://linuxmafia.com/mailman/listinfo/sf-lug
And presently includes:
rick at linuxmafia.com, awsflug at sunnyside.com
So that's Rick Moen and Al Whaley.
> owner, is arriving back
I believe he's already back by now.
> be able to review the issue(s) potentially affecting the SF-LUG
> mailing-list(?)
I'm not aware of any SF-LUG list nor linuxmafia.com list nor
linuxmafia.com
issues ... other than the aforementioned occasional kernel Oops, and
since
linuxmafia.com. is VM hosted on physical host guido, fixing the
filesystem
issue on guido will probably involve some reboot(s) and wee bit of
downtime to take care of that, but I'm not otherwise anticipating any
downtime at this time, and as far as I'm aware, list continues to work
fine.
> ---------------------------- Original Message
> ----------------------------
> Subject: Re: JD's Mathematics programs, SF-LUG Mtg
> From: "aaronco36" <aaronco36 at sdf.org>
> --------------------------------------------------------------------------
>
> Hi Bobbie,
>
> - Robert J. was talking about his AT&T internet service, referring
> back to his original mid-June 2023 posting 'Using Linux with AT&T
> internet
> service.' ; http://linuxmafia.com/pipermail/sf-lug/2023q2/015849.html
> -- the last timely posting on the subject was Rick M's w/in five days
> of the OP's ; http://linuxmafia.com/pipermail/sf-lug/2023q2/015860.html
> -- besides Rick M's candid responses on the subject were replies by Ken
> S.,
> you(Bobbie S.), Michael P., Jim S., and Tom L.
> -- Michael P. provided other related links(??) on the AT&T subject at
> yesterday's meeting
Related link:
http://linuxmafia.com/pipermail/sf-lug/2010q1/007451.html
Basically seen this goop before. It's not matter that ISP (e.g. AT&T)
isn't Linux compatible, but rather they can't be bothered to support it,
don't care to, but shouldn't care nor need to know either.
Hence, e.g. they support some de jur flavors of Microsoft Windows and
MacOS, and that's what they document, provide instructions for such,
and, e.g. their phone answering support staff are given troubleshooting
workflows on. Any other operating system ... unsupported. But of
course they really don't particularly care beyond that, and of course it
works ... except where they set things up not to support it ... or more
specifically what operating system one's browser's User-Agent header
claims to be using. Well, that's quite easy to change - no need to
change operating system to change a header line one's browser sends.
So, basically easy peasy and done, nothin' new here:
Translate their other operating system(s) networking configuration
instructions into generic network configuration instructions and apply.
When their web server complains about operating system not supported and
doesn't otherwise let one proceed further, change browser's User Agent
string and proceed. And if they tell you to install some crud software
on your operating system or in your browser or use their browser, just
don't. Yes, you don't need the Yahoo!/SBC browser with their plugins or
whatever crud they're pushing last decade, this, or next.
> - Jonathan D. elaborated upon his OpenBSD advocacy, including
> mentioning
> that very Maxima you(Bobbie S.) mentioned in your email message on top
> (IMHO, I mentioned my positive current use of FreeBSD-based GhostBSD
> for more *BSD n00Bs like myself, as well as past use of the
> FreeBSD-based live NomadBSD, all mentioned on the SF-LUG mailing-list
> w/in
> the last half-dozen years(??) or so)
Also mentioned about far less bugs and far less bloat in BSD
software, notably compared to GNU, etc. E.g. I provided:
ls -Ls /usr/bin/{{,bsd}{cat,cpio,tar},nvi,vim} | sort -bnr
2652 /usr/bin/vim
472 /usr/bin/nvi
440 /usr/bin/tar
160 /usr/bin/cpio
76 /usr/bin/bsdtar
48 /usr/bin/bsdcpio
44 /usr/bin/cat
16 /usr/bin/bsdcat
> - Victor posed a question on viewing line-number info using the Vim
> editor's vimtutor; Michael P. 1st provided a link to one of his one
> 'vi'
> advocacy webpages and then satisfactorily helped to resolve Victor's
> question specifically for Vim
Uhm, vi presentation/training materials, from presentations I've done on
vi, etc.:
https://www.mpaoli.net/~michael/unix/vi/
If you want advocacy:
https://www.mpaoli.net/~michael/linux/vim/vim_annoyances.txt
And somewhere in the meeting, shell also came up, and I also provided:
https://www.mpaoli.net/~michael/unix/sh/
And, didn't (fully) cover at the meeting ...
So, vim, control-G fails to show the current line number.
Well, if one uses:
:se compatible
to set vim's vi compatible mode (it's not that compatible, but setting
that will make it more vi compatible), then control-G works as expected.
And, interestingly I note, the using:
:se nocompatible
in vim, which one would think would toggle it back ...
well control-G still provides the current line number,
whereas by default it doesn't.
And POSIX and such ...:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/vi.html
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ex.html
"If the edit buffer contains lines, the current line number and the
number of lines in the edit buffer shall be included in this message"
So of course, no surprise, vim isn't POSIX complaint - I don't think it
even aims to be nor cares to be.
More information about the sf-lug
mailing list