On 6/11/2023 5:12 PM, Johnny Billquist wrote:
> 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:
>>>> 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".

Let me try and rephrase and see if you agree with that.

If we approximate security risk as:

f(applications, threats, practices)

then my claim is that:

f(applications_2023, threats_2023, practices_2023) <
f(applications_2023, threats_2023, practices_1983)

and:

f(applications_1983, threats_1983, practices_2023) <
f(applications_1983, threats_1983, practices_1983)

I am not claiming that:

f(applications_2023, threats_2023, practices_2023) <
f(applications_1983, threats_1983, practices_1983)

Arne

On 2023-06-12 01:33, Arne Vajhøj wrote:
> On 6/11/2023 5:12 PM, Johnny Billquist wrote:
>> 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:
>>>>> 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".
>
> Let me try and rephrase and see if you agree with that.
>
> If we approximate security risk as:
>
> f(applications, threats, practices)
>
> then my claim is that:
>
> f(applications_2023, threats_2023, practices_2023) <
> f(applications_2023, threats_2023, practices_1983)
>
> and:
>
> f(applications_1983, threats_1983, practices_2023) <
> f(applications_1983, threats_1983, practices_1983)
>
> I am not claiming that:
>
> f(applications_2023, threats_2023, practices_2023) <
> f(applications_1983, threats_1983, practices_1983)

:-)

Yeah, that I can agree with.

Johnny

On 2023-06-08, Robert A. Brooks <FIRST.LAST@vmssoftware.com> wrote:
> On 6/8/2023 5:31 PM, Pizza RAC wrote:
>
>> you may have to vest DIBOL if it is not ported to x86 by synergy company
>
> I'm not sure what that above means.
>

It's just someone (looks like Bob C.) not understanding how this stuff works.

> 1) There is no translation software for porting Alpha (or IA64) to X86, as has
> been mentioned several times over the past few years here.
>
> 2) Translating an IA64 image of the compiler would create a compiler
> that creates IA64 objects when the newly-translated compiler is run on whatever
> target you've translated to.
>
> If you are referring to images whose source was DIBOL, then see
> statement 1.
>

After VAX Dibol, DEC handed the Dibol market to Synergex and they have
provided Dibol compilers for VMS since then. Bob's statement makes me
wonder if they have decided not to port their compiler to x86-64 VMS.

_If_ so, that could impact a good chunk of your userbase. Perhaps it might
be a good idea for someone at VSI to contact Synergex and see if there
is anything VSI can do to help persuade Synergex to port to x86-64 VMS,
if such a project is not already underway.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2023-06-11, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> 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.
>

If that results in a car with real physical buttons for everything,
that would be an improvement.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2023-06-12, Johnny Billquist <bqt@softjar.se> wrote:
> On 2023-06-12 01:33, Arne Vajhøj wrote:
>>
>> If we approximate security risk as:
>>
>> f(applications, threats, practices)
>>
>> then my claim is that:
>>
>> f(applications_2023, threats_2023, practices_2023) <
>> f(applications_2023, threats_2023, practices_1983)
>>
>> and:
>>
>> f(applications_1983, threats_1983, practices_2023) <
>> f(applications_1983, threats_1983, practices_1983)
>>
>> I am not claiming that:
>>
>> f(applications_2023, threats_2023, practices_2023) <
>> f(applications_1983, threats_1983, practices_1983)
>
>:-)
>
> Yeah, that I can agree with.
>

OTOH, we live in a world where it is acceptable to place an external
internet-based dependency to a left-pad function into a production
code base. :-(

Bloody Javascript programmers will be the death of us all...

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

Simon Clubley wrote:

> Arne Vajhøj wrote:
>
>> Try design a car using 40 year
>> old practices and compare the result to a modern car.
>>
>
> If that results in a car with real physical buttons for everything,
> that would be an improvement.

My 6 year old car has two screens, but neither is a touchscreen, have
they all stopped having physical buttons during that time?

In article <u65e8r$g8o$3@news.misty.com>,
Johnny Billquist <bqt@softjar.se> wrote:
>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...

Oh, do you have a pointer to the grammar? From what little I've
seen, it appears to be context-sensitive.

- Dan C.

On 6/12/2023 8:57 AM, Simon Clubley wrote:
> On 2023-06-08, Robert A. Brooks <FIRST.LAST@vmssoftware.com> wrote:
>> On 6/8/2023 5:31 PM, Pizza RAC wrote:
>>> you may have to vest DIBOL if it is not ported to x86 by synergy company
>>
>> I'm not sure what that above means.

> After VAX Dibol, DEC handed the Dibol market to Synergex and they have
> provided Dibol compilers for VMS since then. Bob's statement makes me
> wonder if they have decided not to port their compiler to x86-64 VMS.
>
> _If_ so, that could impact a good chunk of your userbase. Perhaps it might
> be a good idea for someone at VSI to contact Synergex and see if there
> is anything VSI can do to help persuade Synergex to port to x86-64 VMS,
> if such a project is not already underway.

Software is important for an OS.

VSI should definitely court relevant ISV's.

Synergex would be very relevant for DBL.

But note that it was "... if ...", so it may just
be concerns that Synergex has not said that they will port
instead of has said they they will not port.

It is pretty obvious from their web site that .NET is their
main focus today.

Question is if there is enough VMS customers to warrant
a port.

Does Dibol compile to native? If yes then they would need
to integrate with LLVM backend.

Arne

In article <u689pl$38idu$1@dont-email.me>, arne@vajhoej.dk (Arne Vajh�j)
wrote:

> Does Dibol compile to native? If yes then they would need
> to integrate with LLVM backend.

Looks like a bytecode. So the run-time system for that would need to be
re-built, along with the compiler.

John

On 6/12/2023 9:00 PM, John Dallman wrote:
> In article <u689pl$38idu$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj)
> wrote:
>> Does Dibol compile to native? If yes then they would need
>> to integrate with LLVM backend.
>
> Looks like a bytecode. So the run-time system for that would need to be
> re-built, along with the compiler.

source code to byte code compiler + byte code interpreter

should be easier to port than:

source code to native code compiler

Arne

On 2023-06-12, Andy Burns <usenet@andyburns.uk> wrote:
> Simon Clubley wrote:
>
>> Arne Vajhøj wrote:
>>
>>> Try design a car using 40 year
>>> old practices and compare the result to a modern car.
>>>
>>
>> If that results in a car with real physical buttons for everything,
>> that would be an improvement.
>
> My 6 year old car has two screens, but neither is a touchscreen, have
> they all stopped having physical buttons during that time?
>

It's heading that way (apart from the mandatory controls). :-(

It appears the cretins responsible for "modern" UI designs have now
been let loose on the vehicle UIs.

Some reading for you:

https://www.themanual.com/auto/touchscreen-in-car-less-safe-than-buttons/

Here is a balanced review that discusses both the positive and negative
aspects of touchscreens and categorises the various vehicle controls:

https://www.theturnsignalblog.com/blog/touch-screens/

Finally, here's some research done on modern flat UIs in general:

https://www.nngroup.com/articles/flat-ui-less-attention-cause-uncertainty/

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2023-06-12, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 6/12/2023 9:00 PM, John Dallman wrote:
>> In article <u689pl$38idu$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj)
>> wrote:
>>> Does Dibol compile to native? If yes then they would need
>>> to integrate with LLVM backend.
>>
>> Looks like a bytecode. So the run-time system for that would need to be
>> re-built, along with the compiler.
>
> source code to byte code compiler + byte code interpreter
>
> should be easier to port than:
>
> source code to native code compiler
>

It's bytecode (unless it has changed recently), but the build sequence
on Alpha (the last architecture I used Synergex Dibol on) resulted in
normal VMS executables created using the VMS linker. It looked like the
bytecode was embedded within the executable and the executable was linked
against the Dibol RTL.

You can also call directly (for example) C subroutines and VMS system
services from within your Dibol code (I used to write some low-level
stuff in C that was too slow when implemented directly in Dibol), so
the executables can be regarded as some hybrid of native VMS code and
Dibol bytecode.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 6/13/2023 8:32 AM, Simon Clubley wrote:
> On 2023-06-12, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 6/12/2023 9:00 PM, John Dallman wrote:
>>> In article <u689pl$38idu$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj)
>>> wrote:
>>>> Does Dibol compile to native? If yes then they would need
>>>> to integrate with LLVM backend.
>>>
>>> Looks like a bytecode. So the run-time system for that would need to be
>>> re-built, along with the compiler.
>>
>> source code to byte code compiler + byte code interpreter
>>
>> should be easier to port than:
>>
>> source code to native code compiler
>
> It's bytecode (unless it has changed recently), but the build sequence
> on Alpha (the last architecture I used Synergex Dibol on) resulted in
> normal VMS executables created using the VMS linker. It looked like the
> bytecode was embedded within the executable and the executable was linked
> against the Dibol RTL.

So they will need to:
* build the interpreter module
* build the RTL
* build a stub
* build a compiler that embed stub + interpreter module + byte code

Work.

But I don't think as much work as for a native compiler.

I am sure they wish that .NET was available on VMS. :-)

> You can also call directly (for example) C subroutines and VMS system
> services from within your Dibol code (I used to write some low-level
> stuff in C that was too slow when implemented directly in Dibol), so
> the executables can be regarded as some hybrid of native VMS code and
> Dibol bytecode.

That is pretty standard. Java, Python etc. all has such capabilities.

Arne

On Tue, 2023-06-13 at 09:04 -0400, Arne Vajhøj wrote:
> I am sure they wish that .NET was available on VMS.   :-)

Mono, the open source equivalent of .NET is easily portable to new
architectures.

Now if only VSI could write a graphical driver for use in Virtualbox
and others then we could in theory be able to use DecWindows instead of
using X11 remotely.
--
Tactical Nuclear Kittens

On Tue, 2023-06-13 at 12:24 +0000, Simon Clubley wrote:
> It's heading that way (apart from the mandatory controls). :-(
>
> It appears the cretins responsible for "modern" UI designs have now
> been let loose on the vehicle UIs.

IMHO Displays should show information. Knobs should be easily reachable
and twiddable. Fuck touchscreens!

Teslas are a horrific example of touchscreen mania taken to the
extreme!

BMW's I-Drive uses a twirlable knob and clickable buttons to set
options in the LCD display. Works quite nicely and doesn't detract
attention away from the road.
--
Tactical Nuclear Kittens

On 6/13/2023 10:14 AM, Single Stage to Orbit wrote:
> On Tue, 2023-06-13 at 09:04 -0400, Arne Vajhøj wrote:
>> I am sure they wish that .NET was available on VMS.   :-)
>
> Mono, the open source equivalent of .NET is easily portable to new
> architectures.

AFAIK then Mono is the open source equivalent of closed
source .NET Fx 1.x-4.x while latest and greatest is the
open source .NET Core 1.x-3.x & .NET 5+ flavor.

Unless one has special requirements like .NET Fx compatibility
then .NET 6 would be the obvious target (6 is LTS, 7 is not).

But maybe it is easier to get Mono running than .NET 5+.

Anyway it is certainly not trivial.

The library is huge and as we all know then code working on Linux
does not always work on VMS.

And if speed is required then JIT in the CLR is needed.

> Now if only VSI could write a graphical driver for use in Virtualbox
> and others then we could in theory be able to use DecWindows instead of
> using X11 remotely.

I always believed relative few VMS users used graphics.

But there has been several questions from VMS x86-64
testers.

Arne

Single Stage to Orbit wrote:

> BMW's I-Drive uses a twirlable knob and clickable buttons to set
> options in the LCD display. Works quite nicely and doesn't detract
> attention away from the road.

Mine's not a BMW, but has what I guess is a similar knob in the centre
console. I can also "write" on the top surface of the knob, but in a
RHD car that's far too fiddly unless you're a left-hander, so I never
use that.

On 13/06/2023 16:14, Andy Burns wrote:
> Single Stage to Orbit wrote:
>
>> BMW's I-Drive uses a twirlable knob and clickable buttons to set
>> options in the LCD display. Works quite nicely and doesn't detract
>> attention away from the road.
>
> Mine's not a BMW, but has what I guess is a similar knob in the centre
> console.  I can also "write" on the top surface of the knob, but in a
> RHD car that's far too fiddly unless you're a left-hander, so I never
> use that.
>

You might get some funny looks if seen writing on the top your knob!

--
Chris

On 2023-06-12 15:09, Simon Clubley wrote:
> On 2023-06-12, Johnny Billquist <bqt@softjar.se> wrote:
>> On 2023-06-12 01:33, Arne Vajhøj wrote:
>>>
>>> If we approximate security risk as:
>>>
>>> f(applications, threats, practices)
>>>
>>> then my claim is that:
>>>
>>> f(applications_2023, threats_2023, practices_2023) <
>>> f(applications_2023, threats_2023, practices_1983)
>>>
>>> and:
>>>
>>> f(applications_1983, threats_1983, practices_2023) <
>>> f(applications_1983, threats_1983, practices_1983)
>>>
>>> I am not claiming that:
>>>
>>> f(applications_2023, threats_2023, practices_2023) <
>>> f(applications_1983, threats_1983, practices_1983)
>>
>> :-)
>>
>> Yeah, that I can agree with.
>>
>
> OTOH, we live in a world where it is acceptable to place an external
> internet-based dependency to a left-pad function into a production
> code base. :-(

Yes. That is why that last point from Arne is very relevant, which he
points out he is *not* claiming.

> Bloody Javascript programmers will be the death of us all...

Possibly.

Johnny

On 2023-06-13 16:11, Single Stage to Orbit wrote:
> On Tue, 2023-06-13 at 12:24 +0000, Simon Clubley wrote:
>> It's heading that way (apart from the mandatory controls). :-(
>>
>> It appears the cretins responsible for "modern" UI designs have now
>> been let loose on the vehicle UIs.
>
> IMHO Displays should show information. Knobs should be easily reachable
> and twiddable. Fuck touchscreens!
>
> Teslas are a horrific example of touchscreen mania taken to the
> extreme!
>
> BMW's I-Drive uses a twirlable knob and clickable buttons to set
> options in the LCD display. Works quite nicely and doesn't detract
> attention away from the road.

Agreed. Touch screens for anything beyond navigation in a car should be
explicitly forbidden. Having to twiddle a touch screen to change the
temperature, or deal with seat heating is horrible. There is no tactile
feedback telling me if I'm actually hitting the right button (or any
button at all, and if I actually managed to push it or not). So I *have*
to look at the bloody screen to manipulate basic functionality that I
used to be able to deal with without taking my eyes off the road.

Johnny

On 6/13/2023 8:24 AM, Simon Clubley wrote:
> On 2023-06-12, Andy Burns <usenet@andyburns.uk> wrote:
>> Simon Clubley wrote:
>>
>>> Arne Vajhøj wrote:
>>>
>>>> Try design a car using 40 year
>>>> old practices and compare the result to a modern car.
>>>>
>>>
>>> If that results in a car with real physical buttons for everything,
>>> that would be an improvement.
>>
>> My 6 year old car has two screens, but neither is a touchscreen, have
>> they all stopped having physical buttons during that time?
>>
>
> It's heading that way (apart from the mandatory controls). :-(
>
> It appears the cretins responsible for "modern" UI designs have now
> been let loose on the vehicle UIs.
>
> Some reading for you:
>
> https://www.themanual.com/auto/touchscreen-in-car-less-safe-than-buttons/
>
> Here is a balanced review that discusses both the positive and negative
> aspects of touchscreens and categorises the various vehicle controls:
>
> https://www.theturnsignalblog.com/blog/touch-screens/
>
> Finally, here's some research done on modern flat UIs in general:
>
> https://www.nngroup.com/articles/flat-ui-less-attention-cause-uncertainty/
>
> Simon.
>

I'm not much into touch screens. But I do have a phone, and a tablet. I'm
never sure if a touch will work, sometimes yes, sometimes no. So, in a car,
heading for a tree, touch "BREAK", and nothing happens, while punching on the
screen all the way to the tree.

Well, maybe if a radar was reading the tree, and automatic breaking would be
invoked ....

Recently read some news where the Tesla self driving option had over 700
crashes, and 17 deaths ....

Wonder what the stats on the automatic braking might be ....

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

>> Bloody Javascript programmers will be the death of us all...

This is my first time trying to include an attachment to a newsgroup post.

On Tue, 2023-06-13 at 16:14 +0100, Andy Burns wrote:
> > BMW's I-Drive uses a twirlable knob and clickable buttons to set
> > options in the LCD display. Works quite nicely and doesn't detract
> > attention away from the road.
>
> Mine's not a BMW, but has what I guess is a similar knob in the
> centre console.  I can also "write" on the top surface of the knob,
> but in a RHD car that's far too fiddly unless you're a left-hander,
> so I never use that.

It's perfect for me in RHD cars, but I can't even stick shift in a LHD
car either...
--
Tactical Nuclear Kittens