gah4 <gah4@u.washington.edu> wrote:
>On Wednesday, June 7, 2023 at 5:06:09=E2=80=AFAM UTC-7, Simon Clubley wrote=
>(snip)
>
>> The last time I really used it was decades ago, back when I started in=20
>> the DEC world on RSTS/E at the very start of my career. When I moved to=
>=20
>> VMS and saw TPU, that's when I stopped using TECO.
>
>I am surprised that there isn't a port to C for Unix and Windows.
>
>Then that one could be ported to VMS.

There is. The problem, though, with porting Unix and Windows editors to
VMS, and this goes both for TECO and vi, is that in the Unix and Windows
world all files are stream files and you wind up with editors that can
only operate on stream files. Or even worse (as was the case of a vim
port I used), will convert other files into stream_lf files without warning.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

In article <u61m9k$1q3$1@panix2.panix.com>, kludge@panix.com (Scott
Dorsey) wrote:

> Pretty much all of the things we need to implement very safe
> computing systems were developed in the 1970s and 1980s and
> prototype capability architectures have been tested and used.
> Back then, people were not willing to live with the substantial
> performance hit. Today, that performance hit is even more of a
> problem because so much code is written so much more poorly.

Smart, patient human beings to write good code have always been expensive.
Poor code is just cheaper. The modern way to deal with the problem is to
use lots of (very cheap) CPU power on fuzz testing and static analysis of
code.

John

On 2023-06-10 14:18, Dan Cross wrote:
> In article <u61md6$49j$1@panix2.panix.com>,
> Scott Dorsey <kludge@panix.com> wrote:
>> Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>>> Believe it or not, `sed` is actually Turing complete; I imagine
>>> that TECO is as well. So in some absolute sense, both are
>>> equally powerful.
>>
>> If that were the case, one could write some yacc code to turn sed scripts
>> into teco scripts. This may hurt your brain.
>
> I don't know if yacc would be the best tool for that, but yeah,
> it sounds very doable. It'd be an interesting hack, if nothing
> else.

It would just be pure, utter madness. But for sure, very doable.
yacc is a tool for writing compilers, but I'm almost suspecting it's a
bit of overkill in this case, and might make for a more complex solution
in the end.

But sed to teco seems a somewhat simple problem. Teco to sed could be
much more complicated, I think. Not sure if it would actually be
possible. Turing complete does not tell the full picture. Specifically I
wonder about some OS interactions and system call stuff. In teco you
can, for instance, read and act on individual input characters,
unrelated to the file you are operating on, and turn off and on
character echo, for example. I have no idea if this can even be
accomplished in sed.

Johnny

On 2023-06-10 15:44, Scott Dorsey wrote:
> gah4 <gah4@u.washington.edu> wrote:
>> On Wednesday, June 7, 2023 at 5:06:09=E2=80=AFAM UTC-7, Simon Clubley wrote=
>> (snip)
>>
>>> The last time I really used it was decades ago, back when I started in=20
>>> the DEC world on RSTS/E at the very start of my career. When I moved to=
>> =20
>>> VMS and saw TPU, that's when I stopped using TECO.
>>
>> I am surprised that there isn't a port to C for Unix and Windows.
>>
>> Then that one could be ported to VMS.
>
> There is. The problem, though, with porting Unix and Windows editors to
> VMS, and this goes both for TECO and vi, is that in the Unix and Windows
> world all files are stream files and you wind up with editors that can
> only operate on stream files. Or even worse (as was the case of a vim
> port I used), will convert other files into stream_lf files without warning.

I guess this is the moment in time to mention that teco always view any
file as a stream of bytes, always. When it's written back to disk, it
might do that in whatever format, but while it's in memory, it's a
stream of bytes with both CR and LF in there.

teco is *not* a line editor.

Johnny

On 6/10/2023 7:20 AM, Scott Dorsey wrote:
> Unfortunately the focus today is on speed and low cost. People toss together
> rapid prototypes and put them into production systems. Back in the eighties
> software engineering people talked about code reusability as being a goal
> for improving code quality. Now people just cut and paste library calls
> that they don't understand off of websites and wonder why their machine is
> so slow and insecure.
>
> Pretty much all of the things we need to implement very safe computing
> systems were developed in the 1970s and 1980s and prototype capability
> architectures have been tested and used. Back then, people were not willing
> to live with the substantial performance hit. Today, that performance hit
> is even more of a problem because so much code is written so much more poorly.

Code reuse means library use.

Todays developers knows less about the library functions they use than
they did 40 years ago. Because the number of library functions increased
by a factor 100 or so.

But it would be horrible expensive to develop todays applications
with the libraries from 40 years ago. So very little to do
about that.

Computers are way more secure today than they were 40 years
ago. They have to because the threats have evolved dramatically.

Everything needed to implement safe computing probably existed
40 years ago. But the difficult part of implementing safe
computing is not to have the technology to make it possible or
to use that technology in 98% of cases - the difficult part is
to use it in 100% of cases. It did not happen then and it does
not happen today.

But technology has evolved to help do better. As an example
programming languages in recent years has added null safety
features to try and fix Hoare's billion dollar mistake
(Kotlin, C# 8.0+ etc.).

Arne

kludge@panix.com (Scott Dorsey) writes:

> Rich Alderson <news@alderson.users.panix.com> wrote:

>> I only know enough vi to edit the password file (using the vipw command), or in
>> the old days before autoconfiguration I could edit the Emacs configuration files
>> to install a decent editor.

> What you need to know about vi above all is that it's modal. If you don't
> know what is going on, hit escape and it will put you back into the default
> operating mode. The second thing you need to know is that unlike emacs, you
> cannot edit something that isn't there; the end of a line is the end of a
> line and there is nothing past it until you add something.
>
> Given these two pieces of information you can read the introduction to vi
> that is in the Berkeley 4.1 manual and figure out how to use vi.

That's what I mean by "enough to edit /etc/passwd or Emacs config files". I
never remember all the "d<some character>" (other than "dd" = delete line)
commands, nor the commands to move things into another buffer in order to
insert them later.

> vi is an extension to ed... all the ed commands still work in it, but you
> also get visual editing as a side-effect. It's a line editor with a screen
> editor added to it. What makes it powerful is that it still has all the
> sophisticated command line tools of the line editor. What makes it convenient
> is that it has screen editing functions.

We ran a PDP-11/70 under Unix V7 at the museum; I was the one who managed
accounts on all the running systems, so I had to learn ed in order to modify
the password file.

I love an editor where the only error message is a single "?", and the
accompanying documentation which says that if you get an error, you can figure
out what you did wrong.

> Now, there's stuff that you can't do easily in vi, like working with columns.
> It's a terrible choice for doing ascii art. But for text, I rather like it.
> --scott

Had I met it before 10 years of EMACS (and a couple of Emacs, as well), I might
have tackled it, but I see no need to.

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

Rich Alderson <news@alderson.users.panix.com> wrote:
>That's what I mean by "enough to edit /etc/passwd or Emacs config files". I
>never remember all the "d<some character>" (other than "dd" = delete line)
>commands, nor the commands to move things into another buffer in order to
>insert them later.

Get a vi coffee mug. You don't have to remember anything that you can
conveniently look up.

There is no emacs coffee mug, because it would be too big to lift and nobody
can drink that much coffee anyway.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

cross@spitfire.i.gajendra.net (Dan Cross) writes:

> In article <mddo7lo2nd4.fsf@panix5.panix.com>,
> Rich Alderson <news@alderson.users.panix.com> wrote:

>> I only know enough vi to edit the password file (using the vipw command), or in
>> the old days before autoconfiguration I could edit the Emacs configuration files
>> to install a decent editor.

> Over the years,I've found it useful to retain facility with
> several different editors, selecting between them based on
> context. If I'm working on plan9, I'll use acme or sam; if
> I'm on Unix, vi, though knowing how to use `ed` has been very
> useful in many surprising ways; if I'm programming in Lisp, or
> using Multics or TOPS-20, then emacs; on VMS I use EDT; etc.
> For work-a-day programming these days I like VS Code with the
> language server support.

Fortunately for me, all the systems on which I worked prior to building PGA's
museum had versions of Emacs available. (Well, OK, not the IBM mainframes, but
I could transfer files from a DEC-20 so did my editing there...)

On VMS at the museum, I used TECO because it didn't require a lot of study, as
I was using it on PDP-8 and PDP-11 and DEC-10 systems already.

Different strokes for different folks, no?

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

Scott Dorsey wrote:
> There is no emacs coffee mug

There are Emacs coffee mugs.

Op zondag 11 juni 2023 om 04:03:41 UTC+2 schreef Scott Dorsey:
> Rich Alderson <ne...@alderson.users.panix.com> wrote:
> >That's what I mean by "enough to edit /etc/passwd or Emacs config files". I
> >never remember all the "d<some character>" (other than "dd" = delete line)
> >commands, nor the commands to move things into another buffer in order to
> >insert them later.
> Get a vi coffee mug. You don't have to remember anything that you can
> conveniently look up.
>
> There is no emacs coffee mug, because it would be too big to lift and nobody
> can drink that much coffee anyway.
> --scott
>
> --
> "C'est un Nagra. C'est suisse, et tres, tres precis."

I always liked this one:

https://www.gnu.org/fun/jokes/ed-msg.en.html

:-)

Oswald

>Scott Dorsey wrote:
>> There is no emacs coffee mug
>
>There are Emacs coffee mugs.

How many hundreds of gallons do they hold?
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

Scott Dorsey writes:
>>There are Emacs coffee mugs.
> How many hundreds of gallons do they hold?

The vi espresso cup only needs to say :q!

On 2023-06-11 04:03, Scott Dorsey wrote:
> Rich Alderson <news@alderson.users.panix.com> wrote:
>> That's what I mean by "enough to edit /etc/passwd or Emacs config files". I
>> never remember all the "d<some character>" (other than "dd" = delete line)
>> commands, nor the commands to move things into another buffer in order to
>> insert them later.
>
> Get a vi coffee mug. You don't have to remember anything that you can
> conveniently look up.
>
> There is no emacs coffee mug, because it would be too big to lift and nobody
> can drink that much coffee anyway.

I don't really think we need to revive that religious war.

That said, any editor where the answer is "look it up" to anything you
want to do, is an editor you should not use, in my book.

I'm about at the same level as Rich. I can use vi in an emergency, but
getting emacs or teco is always among the first things I do on any
system I use. Or atleast nano, or *anything* besides vi (and relatives).

Johnny

On 2023-06-11 03:34, Arne Vajhøj wrote:
> On 6/10/2023 7:20 AM, Scott Dorsey wrote:
>> Unfortunately the focus today is on speed and low cost.  People toss
>> together
>> rapid prototypes and put them into production systems.  Back in the
>> eighties
>> software engineering people talked about code reusability as being a goal
>> for improving code quality.  Now people just cut and paste library calls
>> that they don't understand off of websites and wonder why their
>> machine is
>> so slow and insecure.
>>
>> Pretty much all of the things we need to implement very safe computing
>> systems were developed in the 1970s and 1980s and prototype capability
>> architectures have been tested and used.  Back then, people were not
>> willing
>> to live with the substantial performance hit.  Today, that performance
>> hit
>> is even more of a problem because so much code is written so much more
>> poorly.
>
> Code reuse means library use.
>
> Todays developers knows less about the library functions they use than
> they did 40 years ago. Because the number of library functions increased
> by a factor 100 or so.

True. However, I also feel that people in general are less writing
libraries, and more just using them. And instead they copy code and have
several versions of the same code for every different project they work on.

Most people don't even know how to create a library anymore.

> But it would be horrible expensive to develop todays applications
> with the libraries from 40 years ago. So very little to do
> about that.

Also true.

> Computers are way more secure today than they were 40 years
> ago. They have to because the threats have evolved dramatically.

I'm not sure I agree with that. However, the security problems and
issues have shifted a lot.

40 years ago, you had a lot of rather stupid, simple security problems.
Like no encryption on network traffic, little authentication, little
audited code, and so on. So it was very insecure in that way.

Nowadays, those kind of problems are getting scarce. However, programs
these days are so complex, and contain so many components. That means
pretty much noone can really audit or understand the code anymore, and
noone even tries. In addition, since so many things are in the form of
libraries or services that you depend on, any kind of problem in any of
them can potentially affect a whole lot of systems and programs, meaning
any security issue is potentially a very large and severe one. That was
not the case 40 years ago.

So security problems are harder to identify, and have a potentially way
larger impact today. So are we more secure? If you go by the impact of
the security problems 40 years ago and security problems today, then the
impact today is way higher. (Obvious, since people exploiting security
issues have also become way more sophisticated over 40 years, along with
the tools available.)

40 years ago, social engineering was the biggest exploit vector.
Probably not different than today. Just think of War Games as a good
example (pretty close to 40 years ago now).

Johnny

In article <u63a1q$a85$1@panix2.panix.com>,
Scott Dorsey <kludge@panix.com> wrote:
>Rich Alderson <news@alderson.users.panix.com> wrote:
>>That's what I mean by "enough to edit /etc/passwd or Emacs config files". I
>>never remember all the "d<some character>" (other than "dd" = delete line)
>>commands, nor the commands to move things into another buffer in order to
>>insert them later.
>
>Get a vi coffee mug. You don't have to remember anything that you can
>conveniently look up.
>
>There is no emacs coffee mug, because it would be too big to lift and nobody
>can drink that much coffee anyway.

That sounds like a challenge.

- Dan C.

In article <mddilburbyz.fsf@panix5.panix.com>,
Rich Alderson <news@alderson.users.panix.com> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>
>> In article <mddo7lo2nd4.fsf@panix5.panix.com>,
>> Rich Alderson <news@alderson.users.panix.com> wrote:
>
>>> I only know enough vi to edit the password file (using the vipw command), or in
>>> the old days before autoconfiguration I could edit the Emacs configuration files
>>> to install a decent editor.
>
>> Over the years,I've found it useful to retain facility with
>> several different editors, selecting between them based on
>> context. If I'm working on plan9, I'll use acme or sam; if
>> I'm on Unix, vi, though knowing how to use `ed` has been very
>> useful in many surprising ways; if I'm programming in Lisp, or
>> using Multics or TOPS-20, then emacs; on VMS I use EDT; etc.
>> For work-a-day programming these days I like VS Code with the
>> language server support.
>
>Fortunately for me, all the systems on which I worked prior to building PGA's
>museum had versions of Emacs available. (Well, OK, not the IBM mainframes, but
>I could transfer files from a DEC-20 so did my editing there...)
>
>On VMS at the museum, I used TECO because it didn't require a lot of study, as
>I was using it on PDP-8 and PDP-11 and DEC-10 systems already.
>
>Different strokes for different folks, no?

Absolutely! I've never understood editor holy wars. People
should use the tools they're most comfortable with; why does
anyone feel the need to foist their favorite tool onto someone
else?

- Dan C.

In article <u633ve$m32$1@news.misty.com>,
Johnny Billquist <bqt@softjar.se> wrote:
>On 2023-06-10 14:18, Dan Cross wrote:
>> In article <u61md6$49j$1@panix2.panix.com>,
>> Scott Dorsey <kludge@panix.com> wrote:
>>> Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>>>> Believe it or not, `sed` is actually Turing complete; I imagine
>>>> that TECO is as well. So in some absolute sense, both are
>>>> equally powerful.
>>>
>>> If that were the case, one could write some yacc code to turn sed scripts
>>> into teco scripts. This may hurt your brain.
>>
>> I don't know if yacc would be the best tool for that, but yeah,
>> it sounds very doable. It'd be an interesting hack, if nothing
>> else.
>
>It would just be pure, utter madness.

Heh.

>But for sure, very doable.
>yacc is a tool for writing compilers, but I'm almost suspecting it's a
>bit of overkill in this case, and might make for a more complex solution
>in the end.

Yeah. Yacc really wants to generate an LALR(1) parser for a
context-free grammar; that's probably fine for sed, but it does
seem to be a bit like cutting butter with a chainsaw. I don't
know if that would handle TECO, though (quite possibly, but I
don't know enough about TECO's language to say).

>But sed to teco seems a somewhat simple problem. Teco to sed could be
>much more complicated, I think. Not sure if it would actually be
>possible. Turing complete does not tell the full picture. Specifically I
>wonder about some OS interactions and system call stuff. In teco you
>can, for instance, read and act on individual input characters,
>unrelated to the file you are operating on, and turn off and on
>character echo, for example. I have no idea if this can even be
>accomplished in sed.

Indeed. I don't think sed would work for this (one reason I
think that `ed` is a better analogue for TECO).

- Dan C.

In article <u61lv7$hlm$1@panix2.panix.com>,
Scott Dorsey <kludge@panix.com> wrote:
>[snip]
>vi is an extension to ed... all the ed commands still work in it, but you
>also get visual editing as a side-effect. It's a line editor with a screen
>editor added to it. What makes it powerful is that it still has all the
>sophisticated command line tools of the line editor. What makes it convenient
>is that it has screen editing functions.

This is partially true, but `vi` is an extension of `ex`, not
`ed`. The command sets are similar, but not the same, and some
`ed` commands may no work in `vi`.

- Dan C.

On 6/11/2023 9:34 AM, Johnny Billquist wrote:
> Just think of War Games as a good
> example (pretty close to 40 years ago now).
>

As someone who worked with such systems and within DOD
I can assure you that the basic premise of "War Games"
was nonexistent outside the minds of fiction writers.
Much like "Andromeda Strain", "China Syndrome" and
"Jurassic Park".

bill

On 6/11/2023 9:34 AM, Johnny Billquist wrote:
> On 2023-06-11 03:34, Arne Vajhøj wrote:
>> On 6/10/2023 7:20 AM, Scott Dorsey wrote:
>>> Unfortunately the focus today is on speed and low cost.  People toss
>>> together
>>> rapid prototypes and put them into production systems.  Back in the
>>> eighties
>>> software engineering people talked about code reusability as being a
>>> goal
>>> for improving code quality.  Now people just cut and paste library calls
>>> that they don't understand off of websites and wonder why their
>>> machine is
>>> so slow and insecure.
>>>
>>> Pretty much all of the things we need to implement very safe computing
>>> systems were developed in the 1970s and 1980s and prototype capability
>>> architectures have been tested and used.  Back then, people were not
>>> willing
>>> to live with the substantial performance hit.  Today, that
>>> performance hit
>>> is even more of a problem because so much code is written so much
>>> more poorly.
>>
>> Code reuse means library use.
>>
>> Todays developers knows less about the library functions they use than
>> they did 40 years ago. Because the number of library functions increased
>> by a factor 100 or so.
>
> True. However, I also feel that people in general are less writing
> libraries, and more just using them. And instead they copy code and have
> several versions of the same code for every different project they work on.
>
> Most people don't even know how to create a library anymore.

A lot of people still know how and actually do.

The number of available libraries (libraries not functions!) via
Maven (Java), NuGet (.NET), npm (JS) and PyPi (Python) are all
all counted in hundreds of thousands.

>> Computers are way more secure today than they were 40 years
>> ago. They have to because the threats have evolved dramatically.
>
> I'm not sure I agree with that. However, the security problems and
> issues have shifted a lot.
>
> 40 years ago, you had a lot of rather stupid, simple security problems.
> Like no encryption on network traffic, little authentication, little
> audited code, and so on. So it was very insecure in that way.
>
> Nowadays, those kind of problems are getting scarce. However, programs
> these days are so complex, and contain so many components. That means
> pretty much noone can really audit or understand the code anymore, and
> noone even tries. In addition, since so many things are in the form of
> libraries or services that you depend on, any kind of problem in any of
> them can potentially affect a whole lot of systems and programs, meaning
> any security issue is potentially a very large and severe one. That was
> not the case 40 years ago.
>
> So security problems are harder to identify, and have a potentially way
> larger impact today. So are we more secure? If you go by the impact of
> the security problems 40 years ago and security problems today, then the
> impact today is way higher. (Obvious, since people exploiting security
> issues have also become way more sophisticated over 40 years, along with
> the tools available.)
>
> 40 years ago, social engineering was the biggest exploit vector.
> Probably not different than today. Just think of War Games as a good
> example (pretty close to 40 years ago now).

There are 3 aspects:

practices 40 years ago vs practices today
applications 40 years ago vs applications today
threats 40 years ago vs threats today

Applications has become way more complex and are usually
more openly accessible than 40 years ago.

Exploiting vulnerabilities has become an industry with
both criminals and socalled "state actors".

If practices from 40 years ago was used today to develop
applications, then I don't think that would go well.

It is not really surprising. The world progresses. And
it is not unique for IT. Try design a car using 40 year
old practices and compare the result to a modern car.

Arne

On 11/06/2023 18:42, Arne Vajhøj wrote:
> On 6/11/2023 9:34 AM, Johnny Billquist wrote:
>> On 2023-06-11 03:34, Arne Vajhøj wrote:
>>> On 6/10/2023 7:20 AM, Scott Dorsey wrote:
>>>> Unfortunately the focus today is on speed and low cost.  People toss
>>>> together
>>>> rapid prototypes and put them into production systems.  Back in the
>>>> eighties
>>>> software engineering people talked about code reusability as being a
>>>> goal
>>>> for improving code quality.  Now people just cut and paste library
>>>> calls
>>>> that they don't understand off of websites and wonder why their
>>>> machine is
>>>> so slow and insecure.
>>>>
>>>> Pretty much all of the things we need to implement very safe computing
>>>> systems were developed in the 1970s and 1980s and prototype capability
>>>> architectures have been tested and used.  Back then, people were not
>>>> willing
>>>> to live with the substantial performance hit.  Today, that
>>>> performance hit
>>>> is even more of a problem because so much code is written so much
>>>> more poorly.
>>>
>>> Code reuse means library use.
>>>
>>> Todays developers knows less about the library functions they use than
>>> they did 40 years ago. Because the number of library functions increased
>>> by a factor 100 or so.
>>
>> True. However, I also feel that people in general are less writing
>> libraries, and more just using them. And instead they copy code and
>> have several versions of the same code for every different project
>> they work on.
>>
>> Most people don't even know how to create a library anymore.
>
> A lot of people still know how and actually do.
>
> The number of available libraries (libraries not functions!) via
> Maven (Java), NuGet (.NET), npm (JS) and PyPi (Python) are all
> all counted in hundreds of thousands.
>
>>> Computers are way more secure today than they were 40 years
>>> ago. They have to because the threats have evolved dramatically.
>>
>> I'm not sure I agree with that. However, the security problems and
>> issues have shifted a lot.
>>
>> 40 years ago, you had a lot of rather stupid, simple security
>> problems. Like no encryption on network traffic, little
>> authentication, little audited code, and so on. So it was very
>> insecure in that way.
>>
>> Nowadays, those kind of problems are getting scarce. However, programs
>> these days are so complex, and contain so many components. That means
>> pretty much noone can really audit or understand the code anymore, and
>> noone even tries. In addition, since so many things are in the form of
>> libraries or services that you depend on, any kind of problem in any
>> of them can potentially affect a whole lot of systems and programs,
>> meaning any security issue is potentially a very large and severe one.
>> That was not the case 40 years ago.
>>
>> So security problems are harder to identify, and have a potentially
>> way larger impact today. So are we more secure? If you go by the
>> impact of the security problems 40 years ago and security problems
>> today, then the impact today is way higher. (Obvious, since people
>> exploiting security issues have also become way more sophisticated
>> over 40 years, along with the tools available.)
>>
>> 40 years ago, social engineering was the biggest exploit vector.
>> Probably not different than today. Just think of War Games as a good
>> example (pretty close to 40 years ago now).
>
> There are 3 aspects:
>
> practices 40 years ago vs practices today
> applications 40 years ago vs applications today
> threats 40 years ago vs threats today
>
> Applications has become way more complex and are usually
> more openly accessible than 40 years ago.
>
> Exploiting vulnerabilities has become an industry with
> both criminals and socalled "state actors".
>
> If practices from 40 years ago was used today to develop
> applications, then I don't think that would go well.
>
> It is not really surprising. The world progresses. And
> it is not unique for IT. Try design a car using 40 year
> old practices and compare the result to a modern car.
>
> Arne

Just look at light aircraft - most are still using older technology...

--
Chris

On 2023-06-11 18:39, bill wrote:
> On 6/11/2023 9:34 AM, Johnny Billquist wrote:
>>  Just think of War Games as a good example (pretty close to 40 years
>> ago now).
>>
>
> As someone who worked with such systems and within DOD
> I can assure you that the basic premise of "War Games"
> was nonexistent outside the minds of fiction writers.
> Much like "Andromeda Strain", "China Syndrome" and
> "Jurassic Park".

The exact story of War Games might be as ridiculous as you want. That
was not my point.

In War Games, David gains access to the system by social engineering.
Basically, finding the person that have done the work, and figuring out
the password by trying the persons deceased son's name. "Hello,
Professor Falken. How about a nice game of chess."

Which is a perfectly leigitmate, and very effective way to gain access.
Social engineering is by far the most effective way of getting access to
systems. Be that by trying the dog's name, or by befriending the person
and figuring out his favorite lotto number.

Johnny

On 2023-06-11 19:42, Arne Vajhøj wrote:
> On 6/11/2023 9:34 AM, Johnny Billquist wrote:
>> On 2023-06-11 03:34, Arne Vajhøj wrote:
>>> On 6/10/2023 7:20 AM, Scott Dorsey wrote:
>>>> Unfortunately the focus today is on speed and low cost.  People toss
>>>> together
>>>> rapid prototypes and put them into production systems.  Back in the
>>>> eighties
>>>> software engineering people talked about code reusability as being a
>>>> goal
>>>> for improving code quality.  Now people just cut and paste library
>>>> calls
>>>> that they don't understand off of websites and wonder why their
>>>> machine is
>>>> so slow and insecure.
>>>>
>>>> Pretty much all of the things we need to implement very safe computing
>>>> systems were developed in the 1970s and 1980s and prototype capability
>>>> architectures have been tested and used.  Back then, people were not
>>>> willing
>>>> to live with the substantial performance hit.  Today, that
>>>> performance hit
>>>> is even more of a problem because so much code is written so much
>>>> more poorly.
>>>
>>> Code reuse means library use.
>>>
>>> Todays developers knows less about the library functions they use than
>>> they did 40 years ago. Because the number of library functions increased
>>> by a factor 100 or so.
>>
>> True. However, I also feel that people in general are less writing
>> libraries, and more just using them. And instead they copy code and
>> have several versions of the same code for every different project
>> they work on.
>>
>> Most people don't even know how to create a library anymore.
>
> A lot of people still know how and actually do.
>
> The number of available libraries (libraries not functions!) via
> Maven (Java), NuGet (.NET), npm (JS) and PyPi (Python) are all
> all counted in hundreds of thousands.
>
>>> Computers are way more secure today than they were 40 years
>>> ago. They have to because the threats have evolved dramatically.
>>
>> I'm not sure I agree with that. However, the security problems and
>> issues have shifted a lot.
>>
>> 40 years ago, you had a lot of rather stupid, simple security
>> problems. Like no encryption on network traffic, little
>> authentication, little audited code, and so on. So it was very
>> insecure in that way.
>>
>> Nowadays, those kind of problems are getting scarce. However, programs
>> these days are so complex, and contain so many components. That means
>> pretty much noone can really audit or understand the code anymore, and
>> noone even tries. In addition, since so many things are in the form of
>> libraries or services that you depend on, any kind of problem in any
>> of them can potentially affect a whole lot of systems and programs,
>> meaning any security issue is potentially a very large and severe one.
>> That was not the case 40 years ago.
>>
>> So security problems are harder to identify, and have a potentially
>> way larger impact today. So are we more secure? If you go by the
>> impact of the security problems 40 years ago and security problems
>> today, then the impact today is way higher. (Obvious, since people
>> exploiting security issues have also become way more sophisticated
>> over 40 years, along with the tools available.)
>>
>> 40 years ago, social engineering was the biggest exploit vector.
>> Probably not different than today. Just think of War Games as a good
>> example (pretty close to 40 years ago now).
>
> There are 3 aspects:
>
> practices 40 years ago vs practices today
> applications 40 years ago vs applications today
> threats 40 years ago vs threats today
>
> Applications has become way more complex and are usually
> more openly accessible than 40 years ago.
>
> Exploiting vulnerabilities has become an industry with
> both criminals and socalled "state actors".
>
> If practices from 40 years ago was used today to develop
> applications, then I don't think that would go well.
>
> It is not really surprising. The world progresses. And
> it is not unique for IT. Try design a car using 40 year
> old practices and compare the result to a modern car.

Not disagreeing with anything you've said, except that I don't agree
that computer systems have become "way more secure than 40 years ago".

Johnny

On 2023-06-11 16:06, Dan Cross wrote:
> In article <u633ve$m32$1@news.misty.com>,
> Johnny Billquist <bqt@softjar.se> wrote:
>> On 2023-06-10 14:18, Dan Cross wrote:
>>> In article <u61md6$49j$1@panix2.panix.com>,
>>> Scott Dorsey <kludge@panix.com> wrote:
>>>> Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>>>>> Believe it or not, `sed` is actually Turing complete; I imagine
>>>>> that TECO is as well. So in some absolute sense, both are
>>>>> equally powerful.
>>>>
>>>> If that were the case, one could write some yacc code to turn sed scripts
>>>> into teco scripts. This may hurt your brain.
>>>
>>> I don't know if yacc would be the best tool for that, but yeah,
>>> it sounds very doable. It'd be an interesting hack, if nothing
>>> else.
>>
>> It would just be pure, utter madness.
>
> Heh.
>
>> But for sure, very doable.
>> yacc is a tool for writing compilers, but I'm almost suspecting it's a
>> bit of overkill in this case, and might make for a more complex solution
>> in the end.
>
> Yeah. Yacc really wants to generate an LALR(1) parser for a
> context-free grammar; that's probably fine for sed, but it does
> seem to be a bit like cutting butter with a chainsaw. I don't
> know if that would handle TECO, though (quite possibly, but I
> don't know enough about TECO's language to say).

Doable. But I like the analog of butter and chainsaws. That's pretty
much what it feels like in my head.

There is sortof a grammar in teco, but it's rather simplistic. Not that
I think sed is much more complicated, but I'm less familiar with sed...

Johnny

Johnny Billquist <bqt@softjar.se> wrote:
>Which is a perfectly leigitmate, and very effective way to gain access.
>Social engineering is by far the most effective way of getting access to
>systems. Be that by trying the dog's name, or by befriending the person
>and figuring out his favorite lotto number.

Kevin Mitnick says one out of every three whiteboards in offices contains
a password. You just have to discover what it is and what it is the
password for.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."