[COFF] Re: [TUHS] Re: Generational development [was Re: Re: Early GUI on Linux]

[COFF] Re: [TUHS] Re: Generational development [was Re: Re: Early GUI on Linux]

[Dan Cross]

[COFF]

On Mon, Feb 27, 2023 at 4:16 PM Chet Ramey <chet.ramey@case.edu> wrote:
> On 2/27/23 4:01 PM, segaloco wrote:
> > The official Rust book lists a blind script grab from a website piped into a shell as their "official" install mechanism.
>
> Well, I suppose if it's from a trustworthy source...
>
> (Sorry, my eyes rolled so hard they're bouncing on the floor right now.)

I find this a little odd. If I go back to O'Reilly books from the
early 90s, there was advice to do all sorts of suspect things in them,
such as fetching random bits of pieces from random FTP servers (or
even using email fetch tarballs [!!]). Or downloading shell archives
from USENET.

And of course you _can_ download the script and read through it if you want.

And no one forces anyone to use `rustup`. Most vendors ship some
version of Rust through their package management system these days.

        - Dan C.

[COFF] Re: [TUHS] Re: Generational development [was Re: Re: Early GUI on Linux]

[Chet Ramey]

On 2/27/23 4:22 PM, Dan Cross wrote:
> [COFF]
> 
> On Mon, Feb 27, 2023 at 4:16 PM Chet Ramey <chet.ramey@case.edu> wrote:
>> On 2/27/23 4:01 PM, segaloco wrote:
>>> The official Rust book lists a blind script grab from a website piped into a shell as their "official" install mechanism.
>>
>> Well, I suppose if it's from a trustworthy source...
>>
>> (Sorry, my eyes rolled so hard they're bouncing on the floor right now.)
> 
> I find this a little odd. If I go back to O'Reilly books from the
> early 90s, there was advice to do all sorts of suspect things in them,

Sure. My sense is that the world is a less trustworthy place today, that
there are more bad actors out there, and that promoting unsafe practices
like this does little good. If practices like this become the norm (and
they have), it gets very easy to trick someone (or worse, compromise the
server and replace the script with something that does just a little bit
extra). Blindly executing code you get from elsewhere as root isn't a
great idea.

Look at the compromises the Python community has been dealing with
recently, involving replacing common packages on well-known repository
sites with malicious ones.


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

[COFF] Re: [TUHS] Re: Generational development [was Re: Re: Early GUI on Linux]

[Dan Cross]

On Mon, Feb 27, 2023 at 4:42 PM Chet Ramey <chet.ramey@case.edu> wrote:
> On 2/27/23 4:22 PM, Dan Cross wrote:
> > [COFF]
> >
> > On Mon, Feb 27, 2023 at 4:16 PM Chet Ramey <chet.ramey@case.edu> wrote:
> >> On 2/27/23 4:01 PM, segaloco wrote:
> >>> The official Rust book lists a blind script grab from a website piped into a shell as their "official" install mechanism.
> >>
> >> Well, I suppose if it's from a trustworthy source...
> >>
> >> (Sorry, my eyes rolled so hard they're bouncing on the floor right now.)
> >
> > I find this a little odd. If I go back to O'Reilly books from the
> > early 90s, there was advice to do all sorts of suspect things in them,
>
> Sure. My sense is that the world is a less trustworthy place today, that
> there are more bad actors out there, and that promoting unsafe practices
> like this does little good. If practices like this become the norm (and
> they have), it gets very easy to trick someone (or worse, compromise the
> server and replace the script with something that does just a little bit
> extra). Blindly executing code you get from elsewhere as root isn't a
> great idea.

FTR, you don't usually do this as root, as by default `rustup`
installs into $HOME.

I'm not sure how this is any less safe than downloading, say, a
tarball and running the contained `configure` script, except that in
the latter case one at least has the chance to look at the script
contents.

> Look at the compromises the Python community has been dealing with
> recently, involving replacing common packages on well-known repository
> sites with malicious ones.

That seems like an issue that is independent of the delivery mechanism.

FWIW, when my old team brought the Rust toolchain into Google, we
investigated this issue at length. Another team (Android security, I
believe) had used `mrustc`, which is a Rust compiler written in C++,
to bootstrap the "real" Rust compiler from source. We then downloaded
and vendored each dependent crate (Rust library) that we needed, with
an auditing step. So it's entirely possible to work with Rust without
ever using `rustup`.

        - Dan C.

[COFF] Re: [TUHS] Re: Generational development [was Re: Re: Early GUI on Linux]

[Chet Ramey]

On 2/27/23 5:01 PM, Dan Cross wrote:
> On Mon, Feb 27, 2023 at 4:42 PM Chet Ramey <chet.ramey@case.edu> wrote:
>> On 2/27/23 4:22 PM, Dan Cross wrote:
>>> [COFF]
>>>
>>> On Mon, Feb 27, 2023 at 4:16 PM Chet Ramey <chet.ramey@case.edu> wrote:
>>>> On 2/27/23 4:01 PM, segaloco wrote:
>>>>> The official Rust book lists a blind script grab from a website piped into a shell as their "official" install mechanism.
>>>>
>>>> Well, I suppose if it's from a trustworthy source...
>>>>
>>>> (Sorry, my eyes rolled so hard they're bouncing on the floor right now.)
>>>
>>> I find this a little odd. If I go back to O'Reilly books from the
>>> early 90s, there was advice to do all sorts of suspect things in them,
>>
>> Sure. My sense is that the world is a less trustworthy place today, that
>> there are more bad actors out there, and that promoting unsafe practices
>> like this does little good. If practices like this become the norm (and
>> they have), it gets very easy to trick someone (or worse, compromise the
>> server and replace the script with something that does just a little bit
>> extra). Blindly executing code you get from elsewhere as root isn't a
>> great idea.
> 
> FTR, you don't usually do this as root, as by default `rustup`
> installs into $HOME.

You seem to be concentrating on `rustup', which is fine, it's your
preferred example. But just because you don't run `sudo sh' when using
`rustup' doesn't mean there aren't a disturbingly large number of
installers -- or whatever -- for which that is the recommended workflow.
Nor does the fact that `rustup' is a safe example mean that this is a safe
practice in general. I posit that it's a bad idea in general to blindly
run scripts you download from the Internet, and it's especially bad to
do it as root. Depending on how you accept risk, you can choose to do
things about it, but that's often not part of recommendations.

> I'm not sure how this is any less safe than downloading, say, a
> tarball and running the contained `configure` script, except that in
> the latter case one at least has the chance to look at the script
> contents.

Yeah, but with configure you don't want to. :-). In any case, if you want
to, you can have a workflow where you rebuild configure yourself.

> 
>> Look at the compromises the Python community has been dealing with
>> recently, involving replacing common packages on well-known repository
>> sites with malicious ones.
> 
> That seems like an issue that is independent of the delivery mechanism.

I suppose it's workflow-dependent. If your workflow for python development
involves using open-source components (ctx, pytorch, etc.) you get from
some repository like PyPI, you're going to be susceptible to attacks like
this.


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

[COFF] Re: [TUHS] Re: Generational development [was Re: Re: Early GUI on Linux]

[Larry McVoy]

I think you guys are on the same team but are maybe arguing with each
other more than is needed?

On Mon, Feb 27, 2023 at 06:23:32PM -0500, Chet Ramey wrote:
> On 2/27/23 5:01 PM, Dan Cross wrote:
> >On Mon, Feb 27, 2023 at 4:42 PM Chet Ramey <chet.ramey@case.edu> wrote:
> >>On 2/27/23 4:22 PM, Dan Cross wrote:
> >>>[COFF]
> >>>
> >>>On Mon, Feb 27, 2023 at 4:16 PM Chet Ramey <chet.ramey@case.edu> wrote:
> >>>>On 2/27/23 4:01 PM, segaloco wrote:
> >>>>>The official Rust book lists a blind script grab from a website piped into a shell as their "official" install mechanism.
> >>>>
> >>>>Well, I suppose if it's from a trustworthy source...
> >>>>
> >>>>(Sorry, my eyes rolled so hard they're bouncing on the floor right now.)
> >>>
> >>>I find this a little odd. If I go back to O'Reilly books from the
> >>>early 90s, there was advice to do all sorts of suspect things in them,
> >>
> >>Sure. My sense is that the world is a less trustworthy place today, that
> >>there are more bad actors out there, and that promoting unsafe practices
> >>like this does little good. If practices like this become the norm (and
> >>they have), it gets very easy to trick someone (or worse, compromise the
> >>server and replace the script with something that does just a little bit
> >>extra). Blindly executing code you get from elsewhere as root isn't a
> >>great idea.
> >
> >FTR, you don't usually do this as root, as by default `rustup`
> >installs into $HOME.
> 
> You seem to be concentrating on `rustup', which is fine, it's your
> preferred example. But just because you don't run `sudo sh' when using
> `rustup' doesn't mean there aren't a disturbingly large number of
> installers -- or whatever -- for which that is the recommended workflow.
> Nor does the fact that `rustup' is a safe example mean that this is a safe
> practice in general. I posit that it's a bad idea in general to blindly
> run scripts you download from the Internet, and it's especially bad to
> do it as root. Depending on how you accept risk, you can choose to do
> things about it, but that's often not part of recommendations.
> 
> >I'm not sure how this is any less safe than downloading, say, a
> >tarball and running the contained `configure` script, except that in
> >the latter case one at least has the chance to look at the script
> >contents.
> 
> Yeah, but with configure you don't want to. :-). In any case, if you want
> to, you can have a workflow where you rebuild configure yourself.
> 
> >
> >>Look at the compromises the Python community has been dealing with
> >>recently, involving replacing common packages on well-known repository
> >>sites with malicious ones.
> >
> >That seems like an issue that is independent of the delivery mechanism.
> 
> I suppose it's workflow-dependent. If your workflow for python development
> involves using open-source components (ctx, pytorch, etc.) you get from
> some repository like PyPI, you're going to be susceptible to attacks like
> this.
> 
> 
> -- 
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
> 		 ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat

[COFF] Re: [TUHS] Re: Generational development [was Re: Re: Early GUI on Linux]

[Dan Cross]

On Mon, Feb 27, 2023 at 6:42 PM Larry McVoy <lm@mcvoy.com> wrote:
> I think you guys are on the same team but are maybe arguing with each
> other more than is needed?

Hey, the fine old USENET tradition of being in a state of violent agreement!

        - Dan C.


> On Mon, Feb 27, 2023 at 06:23:32PM -0500, Chet Ramey wrote:
> > On 2/27/23 5:01 PM, Dan Cross wrote:
> > >On Mon, Feb 27, 2023 at 4:42 PM Chet Ramey <chet.ramey@case.edu> wrote:
> > >>On 2/27/23 4:22 PM, Dan Cross wrote:
> > >>>[COFF]
> > >>>
> > >>>On Mon, Feb 27, 2023 at 4:16 PM Chet Ramey <chet.ramey@case.edu> wrote:
> > >>>>On 2/27/23 4:01 PM, segaloco wrote:
> > >>>>>The official Rust book lists a blind script grab from a website piped into a shell as their "official" install mechanism.
> > >>>>
> > >>>>Well, I suppose if it's from a trustworthy source...
> > >>>>
> > >>>>(Sorry, my eyes rolled so hard they're bouncing on the floor right now.)
> > >>>
> > >>>I find this a little odd. If I go back to O'Reilly books from the
> > >>>early 90s, there was advice to do all sorts of suspect things in them,
> > >>
> > >>Sure. My sense is that the world is a less trustworthy place today, that
> > >>there are more bad actors out there, and that promoting unsafe practices
> > >>like this does little good. If practices like this become the norm (and
> > >>they have), it gets very easy to trick someone (or worse, compromise the
> > >>server and replace the script with something that does just a little bit
> > >>extra). Blindly executing code you get from elsewhere as root isn't a
> > >>great idea.
> > >
> > >FTR, you don't usually do this as root, as by default `rustup`
> > >installs into $HOME.
> >
> > You seem to be concentrating on `rustup', which is fine, it's your
> > preferred example. But just because you don't run `sudo sh' when using
> > `rustup' doesn't mean there aren't a disturbingly large number of
> > installers -- or whatever -- for which that is the recommended workflow.
> > Nor does the fact that `rustup' is a safe example mean that this is a safe
> > practice in general. I posit that it's a bad idea in general to blindly
> > run scripts you download from the Internet, and it's especially bad to
> > do it as root. Depending on how you accept risk, you can choose to do
> > things about it, but that's often not part of recommendations.
> >
> > >I'm not sure how this is any less safe than downloading, say, a
> > >tarball and running the contained `configure` script, except that in
> > >the latter case one at least has the chance to look at the script
> > >contents.
> >
> > Yeah, but with configure you don't want to. :-). In any case, if you want
> > to, you can have a workflow where you rebuild configure yourself.
> >
> > >
> > >>Look at the compromises the Python community has been dealing with
> > >>recently, involving replacing common packages on well-known repository
> > >>sites with malicious ones.
> > >
> > >That seems like an issue that is independent of the delivery mechanism.
> >
> > I suppose it's workflow-dependent. If your workflow for python development
> > involves using open-source components (ctx, pytorch, etc.) you get from
> > some repository like PyPI, you're going to be susceptible to attacks like
> > this.
> >
> >
> > --
> > ``The lyf so short, the craft so long to lerne.'' - Chaucer
> >                ``Ars longa, vita brevis'' - Hippocrates
> > Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/
>
> --
> ---
> Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat

[COFF] Re: [TUHS] Re: Generational development [was Re: Re: Early GUI on Linux]

[Dan Cross]

On Mon, Feb 27, 2023 at 6:36 PM Chet Ramey <chet.ramey@case.edu> wrote:
> On 2/27/23 5:01 PM, Dan Cross wrote:
> > On Mon, Feb 27, 2023 at 4:42 PM Chet Ramey <chet.ramey@case.edu> wrote:
> >> On 2/27/23 4:22 PM, Dan Cross wrote:
> >>> [COFF]
> >>>
> >>> On Mon, Feb 27, 2023 at 4:16 PM Chet Ramey <chet.ramey@case.edu> wrote:
> >>>> On 2/27/23 4:01 PM, segaloco wrote:
> >>>>> The official Rust book lists a blind script grab from a website piped into a shell as their "official" install mechanism.
> >>>>
> >>>> Well, I suppose if it's from a trustworthy source...
> >>>>
> >>>> (Sorry, my eyes rolled so hard they're bouncing on the floor right now.)
> >>>
> >>> I find this a little odd. If I go back to O'Reilly books from the
> >>> early 90s, there was advice to do all sorts of suspect things in them,
> >>
> >> Sure. My sense is that the world is a less trustworthy place today, that
> >> there are more bad actors out there, and that promoting unsafe practices
> >> like this does little good. If practices like this become the norm (and
> >> they have), it gets very easy to trick someone (or worse, compromise the
> >> server and replace the script with something that does just a little bit
> >> extra). Blindly executing code you get from elsewhere as root isn't a
> >> great idea.
> >
> > FTR, you don't usually do this as root, as by default `rustup`
> > installs into $HOME.
>
> You seem to be concentrating on `rustup', which is fine, it's your
> preferred example.

Huh? Rustup is the context that this came up in:

| On Mon, Feb 27, 2023 at 4:16 PM Chet Ramey <chet.ramey@case.edu> wrote:
| > On 2/27/23 4:01 PM, segaloco wrote:
| > The official Rust book lists a blind script grab from a website
piped into a shell as their "official" install mechanism.
|
| Well, I suppose if it's from a trustworthy source...
|
| (Sorry, my eyes rolled so hard they're bouncing on the floor right now.)

> But just because you don't run `sudo sh' when using
> `rustup' doesn't mean there aren't a disturbingly large number of
> installers -- or whatever -- for which that is the recommended workflow.
>
> Nor does the fact that `rustup' is a safe example mean that this is a safe
> practice in general. I posit that it's a bad idea in general to blindly
> run scripts you download from the Internet, and it's especially bad to
> do it as root. Depending on how you accept risk, you can choose to do
> things about it, but that's often not part of recommendations.

I cannot help but point out that this is moving the goalposts somewhat
from the specific context that I was responding to. If we're now
talking about things in general then I agree with you.

> > I'm not sure how this is any less safe than downloading, say, a
> > tarball and running the contained `configure` script, except that in
> > the latter case one at least has the chance to look at the script
> > contents.
>
> Yeah, but with configure you don't want to. :-).

Hah!

> In any case, if you want
> to, you can have a workflow where you rebuild configure yourself.

This is true, but then there's the autotools source stuff that you've
got to inspect as well, and on and on. Taken to its logical
conclusion, we're reading the source for the package (which, if one
has time, isn't necessarily a bad idea).

I think in the end, running any software package involves taking a
calculated risk in a number of dimensions: there's the obvious
correctness and security aspects, but also legal aspects with respect
to licensing and patents and so forth. For whatever it's worth, a lot
of people have decided that running a script downloaded from some HTTP
server somewhere is acceptable to them, provided it's decently
well-known and so on. Or perhaps they just cargo-cult it and don't
really think about it, which (I think) hews closer to the argument
that folks here have been making.

> >> Look at the compromises the Python community has been dealing with
> >> recently, involving replacing common packages on well-known repository
> >> sites with malicious ones.
> >
> > That seems like an issue that is independent of the delivery mechanism.
>
> I suppose it's workflow-dependent. If your workflow for python development
> involves using open-source components (ctx, pytorch, etc.) you get from
> some repository like PyPI, you're going to be susceptible to attacks like
> this.

Indeed, supply-chain attacks both for software and hardware are
something that the industry generally hasn't given due consideration.
I think that's (slowly) changing. Hopefully we'll see more risk
analysis with respect to this going forward. Maybe the rustup folks
will even change; I've put an inquiry out.

        - Dan C.

[COFF] Re: [TUHS] Re: Generational development [was Re: Re: Early GUI on Linux]

[Chet Ramey]

On 2/27/23 7:28 PM, Dan Cross wrote:

> Huh? Rustup is the context that this came up in:

I think if you look back in the thread, you'll find that the message from
segaloco was a reply to a message of mine where I criticized the practice
of piping from `wget' to `sh'. That's the context.


>> But just because you don't run `sudo sh' when using
>> `rustup' doesn't mean there aren't a disturbingly large number of
>> installers -- or whatever -- for which that is the recommended workflow.
>>
>> Nor does the fact that `rustup' is a safe example mean that this is a safe
>> practice in general. I posit that it's a bad idea in general to blindly
>> run scripts you download from the Internet, and it's especially bad to
>> do it as root. Depending on how you accept risk, you can choose to do
>> things about it, but that's often not part of recommendations.
> 
> I cannot help but point out that this is moving the goalposts somewhat
> from the specific context that I was responding to. If we're now
> talking about things in general then I agree with you.

We were talking about the general practice before Matt used `rustup' as a
specific example. I'm glad we agree it's a bad idea.


>> In any case, if you want
>> to, you can have a workflow where you rebuild configure yourself.
> 
> This is true, but then there's the autotools source stuff that you've
> got to inspect as well, and on and on.

Sure, there's always a limit to where trust takes over. It's ultimately
who you trust to do the packaging: is it your distro/OS vendor, your
package manager (e.g., macports, homebrew), free software distributors
(e.g., signed tar files from gnu.org), or the authors themselves?

> Or perhaps they just cargo-cult it and don't
> really think about it, which (I think) hews closer to the argument
> that folks here have been making.

That's pretty close to the point I was making originally.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

[COFF] Re: [TUHS] Re: Generational development [was Re: Re: Early GUI on Linux]

[Dan Cross]

On Tue, Feb 28, 2023 at 9:53 AM Chet Ramey <chet.ramey@case.edu> wrote:
> On 2/27/23 7:28 PM, Dan Cross wrote:
> > Huh? Rustup is the context that this came up in:
>
> I think if you look back in the thread, you'll find that the message from
> segaloco was a reply to a message of mine where I criticized the practice
> of piping from `wget' to `sh'. That's the context.

Yes, it is quite clear we were speaking past one another.

        - Dan C.

[COFF] Re: [TUHS] Re: Generational development [was Re: Re: Early GUI on Linux]

[Chet Ramey]

On 2/28/23 10:25 AM, Dan Cross wrote:
> On Tue, Feb 28, 2023 at 9:53 AM Chet Ramey <chet.ramey@case.edu> wrote:
>> On 2/27/23 7:28 PM, Dan Cross wrote:
>>> Huh? Rustup is the context that this came up in:
>>
>> I think if you look back in the thread, you'll find that the message from
>> segaloco was a reply to a message of mine where I criticized the practice
>> of piping from `wget' to `sh'. That's the context.
> 
> Yes, it is quite clear we were speaking past one another.

OK, let's not do that any more. :-)

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

[COFF] Re: [TUHS] Generational development [was Re: Re: Early GUI on Linux]

[Dan Cross]

On Mon, Feb 27, 2023 at 4:52 PM Michael Stiller <mstiller@me.com> wrote:
> > I find this a little odd. If I go back to O'Reilly books from the
> > early 90s, there was advice to do all sorts of suspect things in them,
> > such as fetching random bits of pieces from random FTP servers (or
> > even using email fetch tarballs [!!]). Or downloading shell archives
> > from USENET.
> >
> > And of course you _can_ download the script and read through it if you want.
>
> This does not help, you can detect that on the server and send something else.

What? You've already downloaded the script. Once it's on your local
machine, why would you download it again?

> https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/

If I really wanted to see whether it had been tampered with, perhaps
spin up a sacrificial machine and run,

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | tee the.script | sh

and compare to the output of,

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs >
the.script.nopipeshell

        - Dan C.

[COFF] Re: [TUHS] Re: Generational development [was Re: Re: Early GUI on Linux]

[Dan Cross]

On Mon, Feb 27, 2023 at 5:06 PM KenUnix <ken.unix.guy@gmail.com> wrote:
> Have they not heard of common sense? Whenever I get something from git I look through it to
> check for something suspicious before using it and then and only then do I do make install.

Up to what size? What about the dependencies? How about the compiler
that compiles it all?

I have a copy of the Linux kernel I checked out on my machine; it's
many millions of lines of code; sorry, I haven't read all of that. I
often install things using the operating system's package manager; I
haven't read through all that code, either. Life's too short as it is!

> And today's cookie cutter approach to writing software means they are not learning anything
> but copy paste. Where's the innovation?

I imagine that when people made the switch from programming in machine
code to symbolic assemblers, and then again from assembler to
higher-level languages (FORTRAN! COBOL! PL/I!). And so on.

Consider that, perhaps, the innovation is in how those things are all
combined to do something useful for users. My ability to search, read
documents, listen to music, watch real-time video, etc, is way beyond
anything I could do on the machines of the early 90s.

Not everything that the kids do these days is for the better, but not
everything is terrible, either. This list, and TUHS, bluntly, too
often makes the mistake of assuming that it is. Innovation didn't stop
in 1989.

        - Dan C.

> On Mon, Feb 27, 2023 at 4:22 PM Dan Cross <crossd@gmail.com> wrote:
>>
>> [COFF]
>>
>> On Mon, Feb 27, 2023 at 4:16 PM Chet Ramey <chet.ramey@case.edu> wrote:
>> > On 2/27/23 4:01 PM, segaloco wrote:
>> > > The official Rust book lists a blind script grab from a website piped into a shell as their "official" install mechanism.
>> >
>> > Well, I suppose if it's from a trustworthy source...
>> >
>> > (Sorry, my eyes rolled so hard they're bouncing on the floor right now.)
>>
>> I find this a little odd. If I go back to O'Reilly books from the
>> early 90s, there was advice to do all sorts of suspect things in them,
>> such as fetching random bits of pieces from random FTP servers (or
>> even using email fetch tarballs [!!]). Or downloading shell archives
>> from USENET.
>>
>> And of course you _can_ download the script and read through it if you want.
>>
>> And no one forces anyone to use `rustup`. Most vendors ship some
>> version of Rust through their package management system these days.
>>
>>         - Dan C.
>
>
>
> --
> End of line
> JOB TERMINATED
>
>

[COFF] Re: [TUHS] Re: Generational development [was Re: Re: Early GUI on Linux]

[Stuff Received]

On 2023-02-27 17:17, Dan Cross wrote:
> On Mon, Feb 27, 2023 at 5:06 PM KenUnix <ken.unix.guy@gmail.com> wrote:
>> Have they not heard of common sense? Whenever I get something from git I look through it to
>> check for something suspicious before using it and then and only then do I do make install.
> 
> Up to what size? What about the dependencies? How about the compiler
> that compiles it all?
> 
> I have a copy of the Linux kernel I checked out on my machine; it's
> many millions of lines of code; sorry, I haven't read all of that. I
> often install things using the operating system's package manager; I
> haven't read through all that code, either. Life's too short as it is!

Too true.  I build in a restricted account but even so...

(Decades ago, I used Harald Alvestrand's TimeTracker but disabled his 
UDP start-up announcer.  Even though there is not much source, I never 
would known about it had I not read the README.)

S.

[COFF] Re: [TUHS] Re: Generational development [was Re: Re: Early GUI on Linux]

[Dan Cross]

[Redirecting to COFF; TUHS to Bcc:]

On Mon, Feb 27, 2023 at 3:46 PM segaloco via TUHS <tuhs@tuhs.org> wrote:
> I see the wisdom in your last line there, I've typed and deleted a response to this email 4 times, each one more convoluted than the last.
>
> The short of my stance though is, as a younger programmer (29), I am certainly not a fan of these trends that are all too common in my generation.  That said, I've set foot in one single softare-related class in my life (highschool Java class) and so I don't really know what is being taught to folks going the traditional routes.  All I know from my one abortive semester of college is that I didn't see a whole lot of reliance on individual exploration of concepts in classes, just everyone working to a one-size-fits-all understanding of how to be a good employee in a given subject area.  Of course, this is also influenced by my philosophy and biases and such, and only represents 4-5 months of observation, but if my minimal experience with college is to be believed, I have little faith that educational programs are producing much more than meat filters between StackOverflow and <insert code editor here>.  No offense to said meat filters, people gotta work, but there is something lost when the constant march of production torpedoes individual creativity.  Then again, do big firms want sophisticated engineers or are we too far gone into assembly line programming with no personal connection to any of the products?  I'm glad I'm as personally involved in the stuff I work with, I could see myself slipping into the same patterns of apathy if I was a nameless face in a sea of coders on some project I don't even know the legal name of any given day.

This is an extraordinarily complicated subject, and it's really full
of nuance. In general, I think your categorization is unfair.

It sounds like you had a bad experience in your first semester of
college. I can sympathize; I did too.

But a thing to bear in mind is that in the first year, universities
are taking kids (and yes, they are kids...sorry young folks, I don't
mean that as a pejorative, but consider the context! For most young
people this is their first experience living on their own, their first
_real_ taste of freedom, and the first where they're about to be
subject to rigorous academic expectations without a lot of systemic
support) with wildly uneven academic and social backgrounds and
preparing them for advanced study in a particular field...one that
most haven't even identified for themselves yet. For the precocious
student, this will feel stifling; for many others it will be a
struggle. What, perhaps, you see as lack of intellectual curiosity may
have in fact been the outward manifestations of that struggle.

That said...Things are, legitimately, very different today than they
were when Unix was young. The level of complexity has skyrocketed in
every dimension, and things have gotten to the point where hack upon
hack has congealed into a system that's nearly bursting at the seams.
It's honestly amazing that anything works at all.

That said, good things have been invented since 1985, and the way many
of us "grew up" thinking about problems doesn't always apply anymore.
The world changes; c'est la vie.

        - Dan C.

> ------- Original Message -------
> On Monday, February 27th, 2023 at 12:22 PM, arnold@skeeve.com <arnold@skeeve.com> wrote:
>
>
> > Chet Ramey chet.ramey@case.edu wrote:
> >
> > > On 2/27/23 3:04 PM, arnold@skeeve.com wrote:
> > >
> > > > IMHO the dependence upon IDEs is crippling; they cut & paste to the
> > > > almost total exclusion of the keyboard, including when shell completion
> > > > would be faster.
> > >
> > > Don't forget cargo-culting by pasting shell commands they got from the web
> > > and barely understand, if at all.
> >
> >
> > Yeah, really.
> >
> > I do what I can, but it's a very steep uphill battle, as most
> > don't even understand that they're missing something, or that
> > they could learn it if they wanted to.
> >
> > I think I'll stop ranting before I really get going. :-)
> >
> > Arnold