| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 26 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 13:56:13 |
| Calls: | 629 |
| Files: | 1,186 |
| D/L today: |
18 files (29,890K bytes) |
| Messages: | 165,845 |
Hackers are actively exploiting a critical vulnerability
(CVE-2025-32463) in the sudo package
Hackers are actively exploiting a critical vulnerability
(CVE-2025-32463) in the sudo package that enables the
execution of commands with root-level privileges on Linux
operating systems.
c186282 <c186282@nnada.net> wrote:
https://www.bleepingcomputer.com/news/security/cisa-warns-of-critical-linux-sudo-flaw-exploited-in-attacks/
Hackers are actively exploiting a critical vulnerability
(CVE-2025-32463) in the sudo package that enables the
execution of commands with root-level privileges on Linux
operating systems.
This is three months old news, fixed in all major Linux distributions
in early July. Kindly stop making this kind of nonsense noise.
c186282 wrote:
Hackers are actively exploiting a critical vulnerability
(CVE-2025-32463) in the sudo package
I hate to say it, but *if* you're using systemd, it makes sense to
only have one mechanism to launch privileged processes, and use run0
instead of sudo. I don't know if it's ready for prime time yet?
I keep sudo restricted to privileged users (i.e. me), making its vulnerability firehose largely irrelevant.
richard@tsais:~$ ls -l /usr/bin/sudo
-rws--x--- 1 root sudo 232416 Jun 25 13:48 /usr/bin/sudo
On 10/10/25 03:29, Marc Haber wrote:
c186282 <c186282@nnada.net> wrote:
https://www.bleepingcomputer.com/news/security/cisa-warns-of-critical-linux-sudo-flaw-exploited-in-attacks/
Hackers are actively exploiting a critical vulnerability
(CVE-2025-32463) in the sudo package that enables the
execution of commands with root-level privileges on Linux
operating systems.
This is three months old news, fixed in all major Linux distributions
in early July. Kindly stop making this kind of nonsense noise.
Never heard of a sure-enough fix ... just that
they 'knew about' the problem.
c186282 <c186282@nnada.net> wrote:
https://www.bleepingcomputer.com/news/security/cisa-warns-of-critical-linux-sudo-flaw-exploited-in-attacks/
Hackers are actively exploiting a critical vulnerability
( ) in the sudo package that enables the
execution of commands with root-level privileges on Linux
operating systems.
This is three months old news, fixed in all major Linux distributions
in early July. Kindly stop making this kind of nonsense noise.
On 2025-10-10 09:29, Marc Haber wrote:
c186282 <c186282@nnada.net> wrote:
https://www.bleepingcomputer.com/news/security/cisa-warns-of-critical-linux-sudo-flaw-exploited-in-attacks/
September 30, 2025
Hackers are actively exploiting a critical vulnerability
( ) in the sudo package that enables the
execution of commands with root-level privileges on Linux
operating systems.
This is three months old news, fixed in all major Linux distributions
in early July. Kindly stop making this kind of nonsense noise.
True.
Andy Burns <usenet@andyburns.uk> writes:
c186282 wrote:
Hackers are actively exploiting a critical vulnerability
(CVE-2025-32463) in the sudo package
I hate to say it, but *if* you're using systemd, it makes sense to
only have one mechanism to launch privileged processes, and use run0
instead of sudo. I don't know if it's ready for prime time yet?
I keep sudo restricted to privileged users (i.e. me), making its vulnerability firehose largely irrelevant.
On 10/10/2025 11:03, Richard Kettlewell wrote:
I keep sudo restricted to privileged users (i.e. me), making its
vulnerability firehose largely irrelevant.
richard@tsais:~$ ls -l /usr/bin/sudo
-rws--x--- 1 root sudo 232416 Jun 25 13:48 /usr/bin/sudo
Neat, if somewhat paranoid.
c186282 <c186282@nnada.net> wrote:No, asshole ....
On 10/10/25 03:29, Marc Haber wrote:
c186282 <c186282@nnada.net> wrote:
https://www.bleepingcomputer.com/news/security/cisa-warns-of-critical-linux-sudo-flaw-exploited-in-attacks/
Hackers are actively exploiting a critical vulnerability
(CVE-2025-32463) in the sudo package that enables the
execution of commands with root-level privileges on Linux
operating systems.
This is three months old news, fixed in all major Linux distributions
in early July. Kindly stop making this kind of nonsense noise.
Never heard of a sure-enough fix ... just that
they 'knew about' the problem.
If you don't know zilch about what you're talking about you should
shut the fuck up
On 2025-10-10 09:29, Marc Haber wrote:
c186282 <c186282@nnada.net> wrote:
https://www.bleepingcomputer.com/news/security/cisa-warns-of-
critical-linux-sudo-flaw-exploited-in-attacks/
September 30, 2025
Hackers are actively exploiting a critical vulnerability
(-a-a-a ) in the sudo package that enables the
execution of commands with root-level privileges on Linux
operating systems.
This is three months old news, fixed in all major Linux distributions
in early July. Kindly stop making this kind of nonsense noise.
True.
On 10/10/25 06:42, The Natural Philosopher wrote:
On 10/10/2025 11:03, Richard Kettlewell wrote:
I keep sudo restricted to privileged users (i.e. me), making its
vulnerability firehose largely irrelevant.
richard@tsais:~$ ls -l /usr/bin/sudo
-rws--x--- 1 root sudo 232416 Jun 25 13:48 /usr/bin/sudo
Neat, if somewhat paranoid.
-a These days, 'cold' wars getting hotter, BE paranoid.
On 11/10/2025 07:15, c186282 wrote:
On 10/10/25 06:42, The Natural Philosopher wrote:
On 10/10/2025 11:03, Richard Kettlewell wrote:
I keep sudo restricted to privileged users (i.e. me), making its
vulnerability firehose largely irrelevant.
richard@tsais:~$ ls -l /usr/bin/sudo
-rws--x--- 1 root sudo 232416 Jun 25 13:48 /usr/bin/sudo
Neat, if somewhat paranoid.
-a These days, 'cold' wars getting hotter, BE paranoid.I can see absolutely no reason at all, even in my deepest depths of depression and paranoia, why on earth the State, or any other State
could have the slightest interest in me.
I can sleep soundly at night knowing that no one could possibly be out
to get me. I am by design, supremely unimportant.
-a Me, I just un-installed 'sudo'. I've always seen it
-a as a kind of stupid work-around to proper security
-a anyway. Open a terminal and 'su' instead.
Note that a lot of people update like NEVER ...
On 11/10/2025 07:15, c186282 wrote:
On 10/10/25 06:42, The Natural Philosopher wrote:I can see absolutely no reason at all, even in my deepest depths of depression and paranoia, why on earth the State, or any other State
On 10/10/2025 11:03, Richard Kettlewell wrote:
I keep sudo restricted to privileged users (i.e. me), making its
vulnerability firehose largely irrelevant.
richard@tsais:~$ ls -l /usr/bin/sudo
-rws--x--- 1 root sudo 232416 Jun 25 13:48 /usr/bin/sudo
Neat, if somewhat paranoid.
-a-a These days, 'cold' wars getting hotter, BE paranoid.
could have the slightest interest in me.
On Sat, 11 Oct 2025 02:42:58 -0400, c186282 wrote:
Note that a lot of people update like NEVER ...
Thanks for the reminder. I hadn't updated the Fedora box in a few days.
Yep, another new kernel and some Python stuff. Python seems to get a lot
of patches.
YourCOre a target of propaganda from a number of states, like everyone
else. But platform security has at best only tangential relevance to
that.
As for wars: the historical Cold War would have been quite different
with todayrCOs level of computer networking. The USSR would certainly have exploited it in much the same ways that Russia and China do today.
Whether the West would have been any more successful at countering it I hesitate to guess.
On 10/11/25 06:09, The Natural Philosopher wrote:
On 11/10/2025 07:15, c186282 wrote:
On 10/10/25 06:42, The Natural Philosopher wrote:I can see absolutely no reason at all, even in my deepest depths of
On 10/10/2025 11:03, Richard Kettlewell wrote:
I keep sudo restricted to privileged users (i.e. me), making its
vulnerability firehose largely irrelevant.
richard@tsais:~$ ls -l /usr/bin/sudo
-rws--x--- 1 root sudo 232416 Jun 25 13:48 /usr/bin/sudo
Neat, if somewhat paranoid.
-a-a These days, 'cold' wars getting hotter, BE paranoid.
depression and paranoia, why on earth the State, or any other State
could have the slightest interest in me.
-a Just what those old Jews said ........
It's a very imponderable question. I think the level of [mis]information
flow today has meant that people are gradually realising just how much
lies and propaganda there always has been, it's just difficult to hide
it any more.
On 10/11/25 14:48, rbowman wrote:
On Sat, 11 Oct 2025 02:42:58 -0400, c186282 wrote:
-a-a-a Note that a lot of people update like NEVER ...
Thanks for the reminder. I hadn't updated the Fedora box in a few days.
Yep, another new kernel and some Python stuff. Python seems to get a lot
of patches.
-a Lots of things seem to get frequent patches - and FireFox
-a seems to update the entire thing like weekly now.
-a But there does seem to be a fair segment who got sold on
-a the idea that Linux was invulnerable. They install a distro
-a and then NEVER update it.
On 10/10/2025 06:30, c186282 wrote:
-a-a Me, I just un-installed 'sudo'. I've always seen it
-a-a as a kind of stupid work-around to proper security
-a-a anyway. Open a terminal and 'su' instead.
I use sudo out of habit, never really thought about it. I suppose I
could keep an authenticated session alive and set TMOUT to a reasonable value. Or maybe try run0 for the first time ever since I use systemd.
On 10/11/25 09:26, apapmurray wrote:
On 10/10/2025 06:30, c186282 wrote:
-a-a Me, I just un-installed 'sudo'. I've always seen it
-a-a as a kind of stupid work-around to proper security
-a-a anyway. Open a terminal and 'su' instead.
I use sudo out of habit, never really thought about it. I suppose I
could keep an authenticated session alive and set TMOUT to a
reasonable value. Or maybe try run0 for the first time ever since I
use systemd.
-a Sudo basically trashes the user-sep concept
-a in Linux. Really you should NOT install it.
On 13/10/2025 08:07, c186282 wrote:
On 10/11/25 09:26, apapmurray wrote:
On 10/10/2025 06:30, c186282 wrote:
-a-a Me, I just un-installed 'sudo'. I've always seen it
-a-a as a kind of stupid work-around to proper security
-a-a anyway. Open a terminal and 'su' instead.
I use sudo out of habit, never really thought about it. I suppose I
could keep an authenticated session alive and set TMOUT to a
reasonable value. Or maybe try run0 for the first time ever since I
use systemd.
-a-a Sudo basically trashes the user-sep concept
-a-a in Linux. Really you should NOT install it.
I've never had any problem trashing a concept dreamed up by a computer scientist.
To achieve a pragmatic result.
Including code littered with 'go to jail, move directly to jail, do not collect -u200'
What else is try throw and catch?
On 10/13/25 10:42, The Natural Philosopher wrote:
On 13/10/2025 08:07, c186282 wrote:
On 10/11/25 09:26, apapmurray wrote:
On 10/10/2025 06:30, c186282 wrote:
-a-a Me, I just un-installed 'sudo'. I've always seen it
-a-a as a kind of stupid work-around to proper security
-a-a anyway. Open a terminal and 'su' instead.
I use sudo out of habit, never really thought about it. I suppose I
could keep an authenticated session alive and set TMOUT to a
reasonable value. Or maybe try run0 for the first time ever since I
use systemd.
-a-a Sudo basically trashes the user-sep concept
-a-a in Linux. Really you should NOT install it.
I've never had any problem trashing a concept dreamed up by a computer
scientist.
To achieve a pragmatic result.
Including code littered with 'go to jail, move directly to jail, do
not collect -u200'
What else is try throw and catch?
FWIW in C an error handling style pattern using GOTOs, like throw/catch,
was deemed OK. It was only unstructured use of GOTOs that was frowned
upon, i.e. using GOTOs rather than functions.
On 13/10/2025 12:47, Pancho wrote:
FWIW in C an error handling style pattern using GOTOs, like throw/catch,
was deemed OK. It was only unstructured use of GOTOs that was frowned
upon, i.e. using GOTOs rather than functions.
Plenty of code divas will go to any lengths to avoid the dreaded goto.
Despite the fact than in Intel style assembler an if then else is
basically achieved using a conditional branch and a goto...
CMP A,B; if (A = B)
BE S2: ; then goto S2
S1: ; execute else...
JMP S3; ENDIF
S2: ; execute IF TRUE
S3: ENDIF
etc etc.
On 2025-10-13, The Natural Philosopher <tnp@invalid.invalid> wrote:
On 13/10/2025 12:47, Pancho wrote:
FWIW in C an error handling style pattern using GOTOs, like throw/catch, >>> was deemed OK. It was only unstructured use of GOTOs that was frowned
upon, i.e. using GOTOs rather than functions.
Plenty of code divas will go to any lengths to avoid the dreaded goto.
Despite the fact than in Intel style assembler an if then else is
basically achieved using a conditional branch and a goto...
CMP A,B; if (A = B)
BE S2: ; then goto S2
S1: ; execute else...
JMP S3; ENDIF
S2: ; execute IF TRUE
S3: ENDIF
etc etc.
It's funny how CS weenies loudly decry the undisciplined use
of GOTOs, while the undisciplined use of function calls is OK.
It's still spaghetti code - but since a function call is just
a GOTO paired with a COME FROM, you're running double strands.
The other way to spot CS weenies is their gratuitous use of
recursion.
On 13/10/2025 18:41, Charlie Gibbs wrote:
The other way to spot CS weenies is their gratuitous use of
recursion.
Possibly. It can be elegant. Or not.
I used it in a maze building program very successfully.
The other way to spot CS weenies is their gratuitous use of
recursion.
Possibly. It can be elegant. Or not.
I used it in a maze building program very successfully.
On Mon, 13 Oct 2025 19:07:50 +0100
The Natural Philosopher <tnp@invalid.invalid> wrote:
The other way to spot CS weenies is their gratuitous use of
recursion.
Possibly. It can be elegant. Or not.
I used it in a maze building program very successfully.
It definitely has its uses, but CS courses almost never seem to focus
on the *useful* applications because it's much easier to demonstrate
the concept with trivial examples like Fibonacci calculation, which is
dead easy to write but *atrocious* in terms of performance scaling :/
It's funny how CS weenies loudly decry the undisciplined use
of GOTOs, while the undisciplined use of function calls is OK.
It's still spaghetti code - but since a function call is just
a GOTO paired with a COME FROM, you're running double strands.
The other way to spot CS weenies is their gratuitous use of
recursion.
On 2025-10-13, John Ames wrote:
On Mon, 13 Oct 2025 19:07:50 +0100
The Natural Philosopher <tnp@invalid.invalid> wrote:
The other way to spot CS weenies is their gratuitous use of
recursion.
Possibly. It can be elegant. Or not.
I used it in a maze building program very successfully.
It definitely has its uses, but CS courses almost never seem to focus
on the *useful* applications because it's much easier to demonstrate
the concept with trivial examples like Fibonacci calculation, which is
dead easy to write but *atrocious* in terms of performance scaling :/
That may be one of the several examples used because the point there
might be to teach the *concept* of recursion.
At least in the introduction course I went through, the lecturer
actually stressed that. The course taught e.g. functional programming, recursion and imperative programming. And IIRC the lectures did involve precisely examples of something that could be nicely solved with
recursion and something which couldn't.
On this, I really suspect the prevalence of Fibonnaci is because it's somewhat well known as a function, and also easy to explain, so that's
one less thing you have to focus on.
Also, it's a good function to use to teach memoization.
On Mon, 13 Oct 2025 19:07:50 +0100 The Natural Philosopher <tnp@invalid.invalid> wrote:
The other way to spot CS weenies is their gratuitous use of
recursion.
Possibly. It can be elegant. Or not.
I used it in a maze building program very successfully.
It definitely has its uses, but CS courses almost never seem to focus on
the *useful* applications because it's much easier to demonstrate the
concept with trivial examples like Fibonacci calculation, which is dead
easy to write but *atrocious* in terms of performance scaling :/
I think the concern about GOTO as opposed to e.g. a function call where supported is that the function call makes it clear where it is called
and to where it returns, while GOTO does not come with that structure.
On Mon, 13 Oct 2025 23:48:55 +0100, Nuno Silva wrote:
I think the concern about GOTO as opposed to e.g. a function call where
supported is that the function call makes it clear where it is called
and to where it returns, while GOTO does not come with that structure.
It's nowhere near as much fun as siglongjmp() :).
Other than the bad old days of FORTRAN my goto use is local to the
function, something like:
if (test_failed) {
goto exit;
}
It allows the function to have one entrance and one exit without the convoluted and deeply nested conditionals that might be needed otherwise.
I think TNP pointed out in assembler all you have is JMP and its friends.
On 2025-10-13, The Natural Philosopher <tnp@invalid.invalid> wrote:
On 13/10/2025 18:41, Charlie Gibbs wrote:
The other way to spot CS weenies is their gratuitous use of
recursion.
Possibly. It can be elegant. Or not.
I used it in a maze building program very successfully.
That's why I included the word "gratuitous" above.
I once wrote an assembler for the Univac 90/30 (sort of
like the IBM 360). To test the macro processor I wrote
a recursive Towers of Hanoi macro. It generated no code,
just a bunch of MNOTEs telling you where to move the disks.
The program listing itself was the solution.
On 10/13/25 14:22, Charlie Gibbs wrote:
On 2025-10-13, The Natural Philosopher <tnp@invalid.invalid> wrote:
On 13/10/2025 18:41, Charlie Gibbs wrote:
The other way to spot CS weenies is their gratuitous use of
recursion.
Possibly. It can be elegant. Or not.
I used it in a maze building program very successfully.
That's why I included the word "gratuitous" above.
I once wrote an assembler for the Univac 90/30 (sort of like the IBM
360). To test the macro processor I wrote a recursive Towers of Hanoi
macro. It generated no code,
just a bunch of MNOTEs telling you where to move the disks.
The program listing itself was the solution.
Recursion is FUN - if you have the stack/mem to spare. Once wrote an
n-field sort routine that relied on recursion. Nice, small,
satisfying.
But yea, it CAN become stupid. Often a straight-on approach is
quicker and simpler.
CS isn't "practical programming" - not at all.
On Mon, 13 Oct 2025 23:48:55 +0100, Nuno Silva wrote:
I think the concern about GOTO as opposed to e.g. a function call where
supported is that the function call makes it clear where it is called
and to where it returns, while GOTO does not come with that structure.
It's nowhere near as much fun as siglongjmp() :).
Other than the bad old days of FORTRAN my goto use is local to the
function, something like:
if (test_failed) {
goto exit;
}
It allows the function to have one entrance and one exit without the convoluted and deeply nested conditionals that might be needed otherwise.
I think TNP pointed out in assembler all you have is JMP and its friends.
On Mon, 13 Oct 2025 19:07:50 +0100
The Natural Philosopher <tnp@invalid.invalid> wrote:
The other way to spot CS weenies is their gratuitous use of
recursion.
Possibly. It can be elegant. Or not.
I used it in a maze building program very successfully.
It definitely has its uses, but CS courses almost never seem to focus
on the *useful* applications because it's much easier to demonstrate
the concept with trivial examples like Fibonacci calculation, which is
dead easy to write but *atrocious* in terms of performance scaling :/
I think the concern about GOTO as opposed to e.g. a function call where supported is that the function call makes it clear where it is called
and to where it returns, while GOTO does not come with that structure.
This can have an impact in understanding the program, but perhaps more importantly makes it harder to analyze the program. And that's, broadly speaking, what computer science is about.
On Mon, 13 Oct 2025 23:48:55 +0100, Nuno Silva wrote:
I think the concern about GOTO as opposed to e.g. a function call where
supported is that the function call makes it clear where it is called
and to where it returns, while GOTO does not come with that structure.
It's nowhere near as much fun as siglongjmp() :).
Other than the bad old days of FORTRAN my goto use is local to the
function, something like:
if (test_failed) {
goto exit;
}
It allows the function to have one entrance and one exit without the convoluted and deeply nested conditionals that might be needed otherwise.
I think TNP pointed out in assembler all you have is JMP and its friends.
On 10/13/25 20:30, rbowman wrote:
On Mon, 13 Oct 2025 23:48:55 +0100, Nuno Silva wrote:
I think the concern about GOTO as opposed to e.g. a function call where
supported is that the function call makes it clear where it is called
and to where it returns, while GOTO does not come with that structure.
It's nowhere near as much fun as siglongjmp() :).
Other than the bad old days of FORTRAN my goto use is local to the
function, something like:
if (test_failed) {
-a-a-a-a goto exit;
}
It allows the function to have one entrance and one exit without the
convoluted and deeply nested conditionals that might be needed otherwise.
I think TNP pointed out in assembler all you have is JMP and its friends.
-a Goto DOES have good uses. Yea, 'structuring' can
-a sometimes do it, but oft in a messy fashion if
-a you need to jump out of the middle of something.
-a Did an app for a handheld device long back which
-a used goto to good advantage ... made it super easy
-a to jump back and forth in the data-entry 'ladder'.
-a Input for each entry prompt was a few-line little
-a 'module'. With goto you could repeat, or go back,
-a very easily.
-a The problem with goto is that it became severely
-a over-used, created 'spaghetti code' almost impossible
-a to figure out.
Hordes of slightly less than random monkeys can in fact produce
reasonable results,
On 10/14/25 01:30, rbowman wrote:
On Mon, 13 Oct 2025 23:48:55 +0100, Nuno Silva wrote:
I think the concern about GOTO as opposed to e.g. a function call where
supported is that the function call makes it clear where it is called
and to where it returns, while GOTO does not come with that structure.
It's nowhere near as much fun as siglongjmp() :).
Other than the bad old days of FORTRAN my goto use is local to the
function, something like:
if (test_failed) {
-a-a-a-a goto exit;
}
It allows the function to have one entrance and one exit without the
convoluted and deeply nested conditionals that might be needed otherwise.
I think TNP pointed out in assembler all you have is JMP and its friends.
By the time I came to look at an assembler (6502), it had jump
subroutine JSR. I can't remember about pushing parameters on the stack.
It's the same as any other relationship between science and engineering.
You don't want a physicist designing a bridge although the basis of civil engineering is physics. There are universities that offer BS and MSE
programs in software engineering. I don't know how much they differ from
the computer science programs. The local university offers CS and I'm not overly impressed but technology isn't really their forte.
On 10/14/25 10:18, The Natural Philosopher wrote:
Hordes of slightly less than random monkeys can in fact produce
reasonable results,
That depends, a lot of huge government projects suggest they can't. It seemed to me that projects need a few good programmers to influence what
is done, and how it is done. This is especially true where something new
is being developed. A new type of program, not just a variation on
something done previously.
It's why I respected your Gridwatch site, the code might be shit, I
don't know, it doesn't matter, it was a good idea. It is that idea that counts. A lot of programmers don't have ideas.
On 13/10/2025 23:48, Nuno Silva wrote:
I think the concern about GOTO as opposed to e.g. a function call where
supported is that the function call makes it clear where it is called
and to where it returns, while GOTO does not come with that structure.
This can have an impact in understanding the program, but perhaps more
importantly makes it harder to analyze the program. And that's, broadly
speaking, what computer science is about.
No. That is what software engineering is all about.
Computer science is all about theory, elegance and obfuscation.
On 2025-10-14, The Natural Philosopher wrote:
On 13/10/2025 23:48, Nuno Silva wrote:
I think the concern about GOTO as opposed to e.g. a function call where
supported is that the function call makes it clear where it is called
and to where it returns, while GOTO does not come with that structure.
This can have an impact in understanding the program, but perhaps more
importantly makes it harder to analyze the program. And that's, broadly
speaking, what computer science is about.
No. That is what software engineering is all about.
I don't recall such analysis being in software engineering? Isn't it
more of a realm of architecture, program design, design patterns, design documentation, and other relevant engineering documentation?
Computer science is all about theory, elegance and obfuscation.
But said theory includes analysis, say, complexity analysis. And this
can be more easily done(*) if the program is adequately structured into functions and isn't a spaghetti mess.
(*) (That said, this in no way means such analysis is always possible or feasible, merely that it is made easier where possible.)
TBH the often sneered at cargo cult method of writing code is often the best,. Find someone else's design, copy it blindly and bugger with it
till it meets the spec.
On 13/10/2025 19:45, John Ames wrote:
On Mon, 13 Oct 2025 19:07:50 +0100 The Natural PhilosopherCS is about the general use of algorithms it seems to me and
<tnp@invalid.invalid> wrote:
The other way to spot CS weenies is their gratuitous use of
recursion.
Possibly. It can be elegant. Or not.
I used it in a maze building program very successfully.
It definitely has its uses, but CS courses almost never seem to focus
on the *useful* applications because it's much easier to demonstrate
the concept with trivial examples like Fibonacci calculation, which is
dead easy to write but *atrocious* in terms of performance scaling :/
mathematical analysis of them.
It MIGHT be handy for someone who designs CPUs, or writes compilers, but that's it
On 10/14/25 10:18, The Natural Philosopher wrote:
Hordes of slightly less than random monkeys can in fact produceThat depends, a lot of huge government projects suggest they can't. It
reasonable results,
seemed to me that projects need a few good programmers to influence what
is done, and how it is done. This is especially true where something new
is being developed. A new type of program, not just a variation on
something done previously.
Proper software houses like IBM or Oracle have teams of analysts who
look at the problem in depth and write a lot of specs long before any
hairy assed coder gets his hands on it. cheaper software houses bid on
it and get the contract but have no real idea how to manage it.
And once you do draw a flow chart it probably is enough to make you
realise how to make the code much easier to understand by removing the spaghetti and concentrating on the little meatballs.
On Tue, 14 Oct 2025 13:02:24 +0100, The Natural Philosopher wrote:
And once you do draw a flow chart it probably is enough to make you
realise how to make the code much easier to understand by removing the
spaghetti and concentrating on the little meatballs.
If you listen to the computer science experts you will draw a UML diagram nobody understands.
https://en.wikipedia.org/wiki/Unified_Modeling_Language
On Tue, 14 Oct 2025 10:18:33 +0100, The Natural Philosopher wrote:
On 13/10/2025 19:45, John Ames wrote:
On Mon, 13 Oct 2025 19:07:50 +0100 The Natural PhilosopherCS is about the general use of algorithms it seems to me and
<tnp@invalid.invalid> wrote:
The other way to spot CS weenies is their gratuitous use of
recursion.
Possibly. It can be elegant. Or not.
I used it in a maze building program very successfully.
It definitely has its uses, but CS courses almost never seem to focus
on the *useful* applications because it's much easier to demonstrate
the concept with trivial examples like Fibonacci calculation, which is
dead easy to write but *atrocious* in terms of performance scaling :/
mathematical analysis of them.
It MIGHT be handy for someone who designs CPUs, or writes compilers, but
that's it
You know you're talking to a CS grad when they mention Big O. That's not
to say analysis of algorithms isn't important but for many uses that's
been sorted years ago.
I'm not convinced it isn't going to blow up but optimization of AI might
be a useful skill. Even with that we had the fundamentals down back in the '80s but didn't have the hardware to implement more than toy demos.
What else is try throw and catch?
It's funny how CS weenies loudly decry the undisciplined use of
GOTOs, while the undisciplined use of function calls is OK.
The other way to spot CS weenies is their gratuitous use of
recursion.
I once browsed my local university frequented bookshop for books on
computer stuff.
CDS bough things like Knutshg 'fundamental algorithms;' An impenetrable
and pointless exercise in mathematical analysis.
Software engineers or information technologists bought books with
chapters like
'planning and management of complex project design' , purpose and implementation of documentation standards' and 'use of test routines'
'uses and abuses of object orientated philosophy' and so on.
In other words, what you actually need to write software...in a real
world
On Mon, 13 Oct 2025 19:07:50 +0100 The Natural Philosopher <tnp@invalid.invalid> wrote:
The other way to spot CS weenies is their gratuitous use of
recursion.
Possibly. It can be elegant. Or not.
I used it in a maze building program very successfully.
It definitely has its uses, but CS courses almost never seem to focus on
the *useful* applications because it's much easier to demonstrate the
concept with trivial examples like Fibonacci calculation, which is dead
easy to write but *atrocious* in terms of performance scaling :/
The other way to spot CS weenies is their gratuitous use of recursion.
Proper software houses like IBM or Oracle have teams of analysts who
look at the problem in depth and write a lot of specs long before any
hairy assed coder gets his hands on it.
Anybody who buys a book with rCLphilosophyrCY in the title ... probably shouldnrCOt be allowed to manage a software project.
On Tue, 14 Oct 2025 01:44:08 -0400, c186282 wrote:
On 10/13/25 14:22, Charlie Gibbs wrote:
On 2025-10-13, The Natural Philosopher <tnp@invalid.invalid> wrote:
On 13/10/2025 18:41, Charlie Gibbs wrote:
The other way to spot CS weenies is their gratuitous use of
recursion.
Possibly. It can be elegant. Or not.
I used it in a maze building program very successfully.
That's why I included the word "gratuitous" above.
I once wrote an assembler for the Univac 90/30 (sort of like the IBM
360). To test the macro processor I wrote a recursive Towers of Hanoi
macro. It generated no code,
just a bunch of MNOTEs telling you where to move the disks.
The program listing itself was the solution.
Recursion is FUN - if you have the stack/mem to spare. Once wrote an
n-field sort routine that relied on recursion. Nice, small,
satisfying.
But yea, it CAN become stupid. Often a straight-on approach is
quicker and simpler.
CS isn't "practical programming" - not at all.
It's the same as any other relationship between science and engineering.
You don't want a physicist designing a bridge although the basis of civil engineering is physics. There are universities that offer BS and MSE
programs in software engineering. I don't know how much they differ from
the computer science programs. The local university offers CS and I'm not overly impressed but technology isn't really their forte.
On 10/11/25 09:26, apapmurray wrote:
On 10/10/2025 06:30, c186282 wrote:
-a-a Me, I just un-installed 'sudo'. I've always seen it
-a-a as a kind of stupid work-around to proper security
-a-a anyway. Open a terminal and 'su' instead.
I use sudo out of habit, never really thought about it. I suppose I
could keep an authenticated session alive and set TMOUT to a
reasonable value. Or maybe try run0 for the first time ever since I
use systemd.
Sudo basically trashes the user-sep concept
in Linux. Really you should NOT install it.
On 10/14/25 01:30, rbowman wrote:
On Mon, 13 Oct 2025 23:48:55 +0100, Nuno Silva wrote:
I think the concern about GOTO as opposed to e.g. a function call where
supported is that the function call makes it clear where it is called
and to where it returns, while GOTO does not come with that structure.
It's nowhere near as much fun as siglongjmp() :).
Other than the bad old days of FORTRAN my goto use is local to the
function, something like:
if (test_failed) {
-a-a-a-a goto exit;
}
It allows the function to have one entrance and one exit without the
convoluted and deeply nested conditionals that might be needed otherwise.
I think TNP pointed out in assembler all you have is JMP and its friends.
By the time I came to look at an assembler (6502), it had jump
subroutine JSR. I can't remember about pushing parameters on the stack.
On 2025-10-14, Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:
Anybody who buys a book with rCLphilosophyrCY in the title ... probably
shouldnrCOt be allowed to manage a software project.
Ironically, an elective course on logic that I took in university was
labeled "Philosophy 302".
That's where I learned about things like De Morgan's theorem, which
comes in quite handy for programming.
On 13/10/2025 19:45, John Ames wrote:
On Mon, 13 Oct 2025 19:07:50 +0100CS is about the general use of algorithms it seems to me and
The Natural Philosopher <tnp@invalid.invalid> wrote:
The other way to spot CS weenies is their gratuitous use of
recursion.
Possibly. It can be elegant. Or not.
I used it in a maze building program very successfully.
It definitely has its uses, but CS courses almost never seem to focus
on the *useful* applications because it's much easier to demonstrate
the concept with trivial examples like Fibonacci calculation, which is
dead easy to write but *atrocious* in terms of performance scaling :/
mathematical analysis of them.
It MIGHT be handy for someone who designs CPUs, or writes compilers, but that's it
TBH the often sneered at cargo cult method of writing code is often the best,. Find someone else's design, copy it blindly-a and bugger with it
till it meets the spec.
As someone remarked to me 'the reason a bricklayer is so crap is because
if he were any good he wouldn't be laying bricks'...
Hordes of slightly less than random monkeys can in fact produce
reasonable results,
On Tue, 14 Oct 2025 11:08:58 +0100, The Natural Philosopher wrote:
Proper software houses like IBM or Oracle have teams of analysts who
look at the problem in depth and write a lot of specs long before any
hairy assed coder gets his hands on it. cheaper software houses bid on
it and get the contract but have no real idea how to manage it.
I worked on one Department of Defense (War) project. There were over a
year of endless meetings to develop specification document. When it was finally finished the hairy assed coders were to implement it. It didn't matter if implementation discovered the beautiful document was bullshit.
By that time there was so much ego involvement it would be implemented as designed regardless.
A few high profile projects come to mind. Why do you think the F-35 has
had endless software problems?
I also have experience in bidding against companies like Lockheed Martin.
Of course they won the bid and then had the brass bound balls to approach
us to subcontract with them as primary since they didn't have a clue.
On Tue, 14 Oct 2025 23:31:44 GMT, Charlie Gibbs wrote:
On 2025-10-14, Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:
Anybody who buys a book with rCLphilosophyrCY in the title ... probably
shouldnrCOt be allowed to manage a software project.
Ironically, an elective course on logic that I took in university was
labeled "Philosophy 302".
That's where I learned about things like De Morgan's theorem, which
comes in quite handy for programming.
I didnrCOt think philosphers believed in logic ... ;)
I found an explanation of De MorganrCOs Theorem in a book on computing hardware, I think it was. Hard to believe you can find people who write software, who donrCOt understand it. I remember on the Python group some years ago getting into an argument with someone who didnrCOt seem to appreciate that the opposite of
a = b re? a = c
was not
a rea b re? a rea c
but
a rea b reo a rea c
At Mon, 13 Oct 2025 03:07:58 -0400, c186282 <c186282@nnada.net> wrote:
On 10/11/25 09:26, apapmurray wrote:
On 10/10/2025 06:30, c186282 wrote:
-a-a Me, I just un-installed 'sudo'. I've always seen it
-a-a as a kind of stupid work-around to proper security
-a-a anyway. Open a terminal and 'su' instead.
I use sudo out of habit, never really thought about it. I suppose I
could keep an authenticated session alive and set TMOUT to a
reasonable value. Or maybe try run0 for the first time ever since I
use systemd.
Sudo basically trashes the user-sep concept
in Linux. Really you should NOT install it.
Okay, I'll bite: What solution do you have to manage multiple
users who need "root" privileges, without giving everybody
the root password?
The only other one I can think of is using multiple ssh
public keys, and setting environment variables (and potentially
a command list) based on the user's key. That can be done, but
has the disadvantage that everybody is running around with
a root shell, rather than running "sudo admin command".
(Ignoring "sudo -i", which is helpful in some cases.)
On 10/14/25 19:41, vallor wrote:
At Mon, 13 Oct 2025 03:07:58 -0400, c186282 <c186282@nnada.net>
wrote:
On 10/11/25 09:26, apapmurray wrote:
On 10/10/2025 06:30, c186282 wrote:
-a-a Me, I just un-installed 'sudo'. I've always seen it
-a-a as a kind of stupid work-around to proper security
-a-a anyway. Open a terminal and 'su' instead.
I use sudo out of habit, never really thought about it. I suppose
I could keep an authenticated session alive and set TMOUT to a
reasonable value. Or maybe try run0 for the first time ever since
I use systemd.
Sudo basically trashes the user-sep concept
in Linux. Really you should NOT install it.
Okay, I'll bite: What solution do you have to manage multiple
users who need "root" privileges, without giving everybody
the root password?
If they "need" it then you give them the root PW.
If they don't "need" it then tuff titty.
The only other one I can think of is using multiple ssh
public keys, and setting environment variables (and potentially
a command list) based on the user's key. That can be done, but
has the disadvantage that everybody is running around with
a root shell, rather than running "sudo admin command".
(Ignoring "sudo -i", which is helpful in some cases.)
Worst case you're dealing with a program that is too complex and you
recall something about this from university lectures and you know what
to look up.
Look into Ada ... not only hyper-anal unto itself but, as mentioned,
every tiny thing involved committees of people writing micro-fine
specs and goals that might not be achievable with that
preferred/required language.
Anybody who buys a book with rCLphilosophyrCY in the title ... probably shouldnrCOt be allowed to manage a software project.
Okay, I'll bite: What solution do you have to manage multiple users who
need "root" privileges, without giving everybody the root password?
On 2025-10-14, Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:
Anybody who buys a book with rCLphilosophyrCY in the title ... probably
shouldnrCOt be allowed to manage a software project.
Ironically, an elective course on logic that I took in university was
labeled "Philosophy 302".
That's where I learned about things like De Morgan's theorem, which
comes in quite handy for programming.
On Tue, 14 Oct 2025 23:31:44 GMT, Charlie Gibbs wrote:
On 2025-10-14, Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:
Anybody who buys a book with rCLphilosophyrCY in the title ... probably
shouldnrCOt be allowed to manage a software project.
Ironically, an elective course on logic that I took in university was
labeled "Philosophy 302".
That's where I learned about things like De Morgan's theorem, which
comes in quite handy for programming.
I didnrCOt think philosphers believed in logic ... ;)
I found an explanation of De MorganrCOs Theorem in a book on computing hardware, I think it was. Hard to believe you can find people who write software, who donrCOt understand it. I remember on the Python group some years ago getting into an argument with someone who didnrCOt seem to appreciate that the opposite of
a = b re? a = c
was not
a rea b re? a rea c
but
a rea b reo a rea c
On 10/14/25 05:18, The Natural Philosopher wrote:
TBH the often sneered at cargo cult method of writing code is often the
best,. Find someone else's design, copy it blindly-a and bugger with it
till it meets the spec.
Today that IS the fastest way. SO many good little
examples, oft with cryptic syntax/params, that can
be tweaked a bit to fit the particular need. Not
going to try and learn everything about TCP stacks
and sockets in Python - just find/cut/paste/tweak.
Gotta have the brains to tweak properly however ...
nine lines of example might need to be fleshed out
into 50+ lines to be very useful.
On Tue, 14 Oct 2025 23:31:44 GMT, Charlie Gibbs wrote:
On 2025-10-14, Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:
Anybody who buys a book with rCLphilosophyrCY in the title ... probably
shouldnrCOt be allowed to manage a software project.
Ironically, an elective course on logic that I took in university was
labeled "Philosophy 302".
That's where I learned about things like De Morgan's theorem, which
comes in quite handy for programming.
I didnrCOt think philosphers believed in logic ... ;)
I found an explanation of De MorganrCOs Theorem in a book on computing hardware, I think it was. Hard to believe you can find people who write software, who donrCOt understand it. I remember on the Python group some years ago getting into an argument with someone who didnrCOt seem to appreciate that the opposite of
a = b re? a = c
was not
a rea b re? a rea c
but
a rea b reo a rea c
On Tue, 14 Oct 2025 21:46:32 -0400, c186282 wrote:
Look into Ada ... not only hyper-anal unto itself but, as mentioned,
every tiny thing involved committees of people writing micro-fine
specs and goals that might not be achievable with that
preferred/required language.
No thanks. My memories of Ada are from the '80s. Pre-LinkIn etc the Sunday Boston Globe was the go-to for technical job offerings. There were ads for Ada programmers with three years of experience. At the time there wasn't a working Ada compiler. Some things never change.
On Tue, 14 Oct 2025 23:27:05 +0100, Nuno Silva wrote:
Worst case you're dealing with a program that is too complex and you
recall something about this from university lectures and you know what
to look up.
When I learned FORTRAN IV in '65 it wasn't considered 'computer science'
but a technique like using a slide rule. I think Dartmouth was the first university to consider it more than the bastard child of the math department.
Today that IS the fastest way. SO many good little examples, oft with
cryptic syntax/params, that can be tweaked a bit to fit the
particular need. Not going to try and learn everything about TCP
stacks and sockets in Python - just find/cut/paste/tweak. Gotta have
the brains to tweak properly however ...
nine lines of example might need to be fleshed out into 50+ lines to
be very useful.
On 2025-10-14, rbowman wrote:
On Tue, 14 Oct 2025 13:02:24 +0100, The Natural Philosopher wrote:
And once you do draw a flow chart it probably is enough to make you
realise how to make the code much easier to understand by removing the
spaghetti and concentrating on the little meatballs.
If you listen to the computer science experts you will draw a UML
diagram nobody understands.
https://en.wikipedia.org/wiki/Unified_Modeling_Language
I'm confident UML is from software engineering, not computer science :-P
On 2025-10-15, c186282 <c186282@nnada.net> wrote:
On 10/14/25 05:18, The Natural Philosopher wrote:
TBH the often sneered at cargo cult method of writing code is often the
best,. Find someone else's design, copy it blindly-a and bugger with it
till it meets the spec.
Today that IS the fastest way. SO many good little
examples, oft with cryptic syntax/params, that can
be tweaked a bit to fit the particular need. Not
going to try and learn everything about TCP stacks
and sockets in Python - just find/cut/paste/tweak.
Gotta have the brains to tweak properly however ...
nine lines of example might need to be fleshed out
into 50+ lines to be very useful.
My personal C library contains functions to do my favourite
socket operations (e.g. create a socket and establish a
TCP/IP connection, with flags specifying whether it's
blocking or not). Takes a lot of the work out of it.
On 2025-10-14, The Natural Philosopher <tnp@invalid.invalid> wrote:
TBH the often sneered at cargo cult method of writing code is often the
best,. Find someone else's design, copy it blindly and bugger with it
till it meets the spec.
Perhaps, but beware - if you take this as an excuse to not understand
how it works, you'll be screwed when it breaks.
On Tue, 14 Oct 2025 10:31:39 +0100, Pancho wrote:I was on a project that had been specified by a compsci. We had nearly
On 10/14/25 10:18, The Natural Philosopher wrote:
Hordes of slightly less than random monkeys can in fact produceThat depends, a lot of huge government projects suggest they can't. It
reasonable results,
seemed to me that projects need a few good programmers to influence what
is done, and how it is done. This is especially true where something new
is being developed. A new type of program, not just a variation on
something done previously.
https://en.wikipedia.org/wiki/The_Mythical_Man-Month
The specifics are 50 years out of date but it should be required reading
for every programmer and project manager. 'Hire more monkeys!' isn't a
viable strategy.
I also have experience in bidding against companies like Lockheed Martin.
Of course they won the bid and then had the brass bound balls to approach
us to subcontract with them as primary since they didn't have a clue.
On 2025-10-14, rbowman wrote:
On Tue, 14 Oct 2025 13:02:24 +0100, The Natural Philosopher wrote:
And once you do draw a flow chart it probably is enough to make you
realise how to make the code much easier to understand by removing the
spaghetti and concentrating on the little meatballs.
If you listen to the computer science experts you will draw a UML diagram
nobody understands.
https://en.wikipedia.org/wiki/Unified_Modeling_Language
I'm confident UML is from software engineering, not computer science :-P
As I said, I always sucked at formal logic. For me logic is verbal, not mathematical and I can never remember what all the weird little symbolsThey actually *mean* something?
mean.
I suppose there's nothing wrong with CS ... but
-a on the flip, how much good or good stuff comes
-a it either ?
-a CS is just a branch of theoretical math. I'd like
-a some figures on how many CS people can write a
-a good old "Hello World".
Okay, I'll bite: What solution do you have to manage multiple
users who need "root" privileges, without giving everybody
the root password?
On 10/14/25 19:41, vallor wrote:
At Mon, 13 Oct 2025 03:07:58 -0400, c186282 <c186282@nnada.net> wrote:
On 10/11/25 09:26, apapmurray wrote:
On 10/10/2025 06:30, c186282 wrote:
-a-a-a Me, I just un-installed 'sudo'. I've always seen it
-a-a-a as a kind of stupid work-around to proper security
-a-a-a anyway. Open a terminal and 'su' instead.
I use sudo out of habit, never really thought about it. I suppose I
could keep an authenticated session alive and set TMOUT to a
reasonable value. Or maybe try run0 for the first time ever since I
use systemd.
-a-a-a Sudo basically trashes the user-sep concept
-a-a-a in Linux. Really you should NOT install it.
Okay, I'll bite:-a What solution do you have to manage multiple
users who need "root" privileges, without giving everybody
the root password?
-a If they "need" it then you give them the root PW.
-a If they don't "need" it then tuff titty.
On Tue, 14 Oct 2025 23:41:31 +0000, vallor wrote:I crashed a development server once with 50+ users on it using root
Okay, I'll bite: What solution do you have to manage multiple users who
need "root" privileges, without giving everybody the root password?
I don't know if it preceded sudo but we had a hack called gosu. Everyone compiled it using their own credentials but then became root to run chmod 4755. Super secure but it didn't matter. The root password for all AIX and Linux boxes was a certain star in the Wolf system.
I was confused with my first Linux install that didn't really have a root password. Prior to that I can't remember the distro, maybe SUSE, but when
you were running as root the wallpaper changed to a red background with
black cartoon bombs with burning fuses. Someone had a sense of humor.
There were occasional mishaps. One guy on an AIX box ran out of room and deleted AIX's equivalent of /usr/bin. I forget what the directory was
called but it didn't *sound* that important.
On 2025-10-15, c186282 <c186282@nnada.net> wrote:
On 10/14/25 05:18, The Natural Philosopher wrote:
TBH the often sneered at cargo cult method of writing code is often the
best,. Find someone else's design, copy it blindly-a and bugger with it
till it meets the spec.
Today that IS the fastest way. SO many good little
examples, oft with cryptic syntax/params, that can
be tweaked a bit to fit the particular need. Not
going to try and learn everything about TCP stacks
and sockets in Python - just find/cut/paste/tweak.
Gotta have the brains to tweak properly however ...
nine lines of example might need to be fleshed out
into 50+ lines to be very useful.
My personal C library contains functions to do my favourite
socket operations (e.g. create a socket and establish a
TCP/IP connection, with flags specifying whether it's
blocking or not). Takes a lot of the work out of it.
On 14/10/2025 23:20, Nuno Silva wrote:
On 2025-10-14, rbowman wrote:Judging by the use of BigWordsrao it is firmly CompSci.
On Tue, 14 Oct 2025 13:02:24 +0100, The Natural Philosopher wrote:
And once you do draw a flow chart it probably is enough to make you
realise how to make the code much easier to understand by removing the >>>> spaghetti and concentrating on the little meatballs.
If you listen to the computer science experts you will draw a UML diagram >>> nobody understands.
https://en.wikipedia.org/wiki/Unified_Modeling_Language
I'm confident UML is from software engineering, not computer science :-P
That's definitely a better example, though for classroom purposes it'dIt definitely has its uses, but CS courses almost never seem to
focus on the *useful* applications because it's much easier to
demonstrate the concept with trivial examples like Fibonacci
calculation, which is dead easy to write but *atrocious* in terms
of performance scaling :/
My first exposure to recursion was not Fibonacci, but AckermannrCOs function.
Feel free to try to come up with a non-recursive implementation of
that. ;)