Hi.

Just heard a rumor that there is no plan for DFU on x86-64.
Any comments on that?

Jan-Erik.

On 2023-04-05, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
> Hi.
>
> Just heard a rumor that there is no plan for DFU on x86-64.
> Any comments on that?
>

Interesting. And very surprising. :-(

DFU does a lot of low-level stuff, but it's the kind of low-level stuff
that should have moved over unchanged to x86-64.

I could _easily_ understand this if a new filesystem was in play, but
for the existing filesystems and $QIO/etc interfaces, I would have
expected this to "just work" on x86-64.

Did they give you a reason why there was no plan to support DFU on x86-64 ?

Simon.

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

On 4/5/2023 4:35 AM, Jan-Erik Söderholm wrote:
> Just heard a rumor that there is no plan for DFU on x86-64.
> Any comments on that?

I believe DFU is a private project by Jur van der Burg.

But first thing must be to get from rumor to fact. Have
you asked him directly about whether he will make a x86-64
build available. If not then it could be relevant to
ask whether he could and will make the sources available
to enable somebody else to build.

(my assumption is that for ODS-2 and ODS-5 it will just be
a simple rebuild - when the new file system arrive one day
out in the future, then real changes may be needed)

Arne

On 4/5/2023 8:19 AM, Arne Vajhøj wrote:
> On 4/5/2023 4:35 AM, Jan-Erik Söderholm wrote:
>> Just heard a rumor that there is no plan for DFU on x86-64.
>> Any comments on that?
>
> I believe DFU is a private project by Jur van der Burg.
>
> But first thing must be to get from rumor to fact. Have
> you asked him directly about whether he will make a x86-64
> build available. If not then it could be relevant to
> ask whether he could and will make the sources available
> to enable somebody else to build.
>
> (my assumption is that for ODS-2 and ODS-5 it will just be
> a simple rebuild - when the new file system arrive one day
> out in the future, then real changes may be needed)

And just in case people are looking or the link:

https://www.digiater.nl/dfu.html

Arne

On 4/5/2023 4:35 AM, Jan-Erik Söderholm wrote:
> Hi.
>
> Just heard a rumor that there is no plan for DFU on x86-64.
> Any comments on that?
>
> Jan-Erik.

Perhaps the thought is that everyone is now using SSDs, and not so much need for
DFU?

--
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

On 4/5/2023 9:21 AM, Dave Froble wrote:
> On 4/5/2023 4:35 AM, Jan-Erik Söderholm wrote:
>> Just heard a rumor that there is no plan for DFU on x86-64.
>> Any comments on that?
>
> Perhaps the thought is that everyone is now using SSDs, and not so much
> need for DFU?

Many DFU features sounds relevant for SSD as well (just not defrag).

And even for defrag then VSI has ported DFG to x86-64 per:
https://vmssoftware.com/products/disk-file-optimizer/

Arne

On 4/5/2023 9:29 AM, Arne Vajhøj wrote:

> Many DFU features sounds relevant for SSD as well (just not defrag).
>
> And even for defrag then VSI has ported DFG to x86-64 per:
>   https://vmssoftware.com/products/disk-file-optimizer/

Yeah, I did that; it was pretty much simply recompile the code and ensure that
nothing broke.

--
-- Rob

On 4/5/2023 10:50 AM, Robert A. Brooks wrote:
> On 4/5/2023 9:29 AM, Arne Vajhøj wrote:
>> Many DFU features sounds relevant for SSD as well (just not defrag).
>>
>> And even for defrag then VSI has ported DFG to x86-64 per:
>>    https://vmssoftware.com/products/disk-file-optimizer/
>
> Yeah, I did that; it was pretty much simply recompile the code and
> ensure that
> nothing broke.

VMS is VMS.

:-)

There tend to be a lot of negative talk about the burden VMS has
from decisions made in the late 70's when VMS was created and
decisions made in the early 90's when porting from VAX to Alpha -
along the lines of "why do we still do XYZ when it does no longer
make any sense".

But there is an upside to that backwards compatibility. One does
not port from VAX to Alpha to Itanium to x86-64. One just rebuild.

Arne

Den 2023-04-05 kl. 15:29, skrev Arne Vajhøj:
> On 4/5/2023 9:21 AM, Dave Froble wrote:
>> On 4/5/2023 4:35 AM, Jan-Erik Söderholm wrote:
>>> Just heard a rumor that there is no plan for DFU on x86-64.
>>> Any comments on that?
>>
>> Perhaps the thought is that everyone is now using SSDs, and not so much
>> need for DFU?
>
> Many DFU features sounds relevant for SSD as well (just not defrag).
>
> And even for defrag then VSI has ported DFG to x86-64 per:
>   https://vmssoftware.com/products/disk-file-optimizer/
>
> Arne
>

We (and the source where I heard this) only uses DFU for non-update
tasks. There are many nice search and report features in DFU. And
at least my source has a strict ban against using DFU for anything
that updates disk data.

My source is a major VMS user in Sweden that is in the work of their
IA64 to x86-64 migration. They goes through all their 3-party tools
and DFU has been "red-flagged".

My source wrote:

"DFU is unfortunately flagged red. Its a freeware and the maintainer
is not interested in porting this to x86-64. We have asked VSI but
have not got any positive answer. They are probably fully occupied
with their own software, and there might be parts of DFU that VSI
might not want to take responsability for, like DEFRAGMENT, MODIFY,
UNDELETE and VERIFY".

I have no idea if they actually have been in contact with the DFU
maintainer, or if that is hearsay. Or if they have got any other
reply from VSI apart from a "positive" one.

Probably not a show-stopper for the x86-64 migration (I think they
definitely will migrate), but might need rewrite of a few routines.

So, I guess the question is if there is someone else that would like
to pick up the DFU sources and try a x86 build...

On Thursday, April 6, 2023 at 6:58:02 AM UTC+1, Jan-Erik Söderholm wrote:
> Den 2023-04-05 kl. 15:29, skrev Arne Vajhøj:
> > On 4/5/2023 9:21 AM, Dave Froble wrote:
> >> On 4/5/2023 4:35 AM, Jan-Erik Söderholm wrote:
> >>> Just heard a rumor that there is no plan for DFU on x86-64.
> >>> Any comments on that?
> >>
> >> Perhaps the thought is that everyone is now using SSDs, and not so much
> >> need for DFU?
> >
> > Many DFU features sounds relevant for SSD as well (just not defrag).
> >
> > And even for defrag then VSI has ported DFG to x86-64 per:
> > https://vmssoftware.com/products/disk-file-optimizer/
> >
> > Arne
> >
> We (and the source where I heard this) only uses DFU for non-update
> tasks. There are many nice search and report features in DFU. And
> at least my source has a strict ban against using DFU for anything
> that updates disk data.
>
> My source is a major VMS user in Sweden that is in the work of their
> IA64 to x86-64 migration. They goes through all their 3-party tools
> and DFU has been "red-flagged".
>
> My source wrote:
>
> "DFU is unfortunately flagged red. Its a freeware and the maintainer
> is not interested in porting this to x86-64. We have asked VSI but
> have not got any positive answer. They are probably fully occupied
> with their own software, and there might be parts of DFU that VSI
> might not want to take responsability for, like DEFRAGMENT, MODIFY,
> UNDELETE and VERIFY".
>
> I have no idea if they actually have been in contact with the DFU
> maintainer, or if that is hearsay. Or if they have got any other
> reply from VSI apart from a "positive" one.
>
> Probably not a show-stopper for the x86-64 migration (I think they
> definitely will migrate), but might need rewrite of a few routines.
>
> So, I guess the question is if there is someone else that would like
> to pick up the DFU sources and try a x86 build...

Such are the risks of relying on freeware maintained by one person even if it is a useful too like DFU. IIRC Jur saved DFU by taking it over from the original author and improving it. Perhaps it's time again.

I made daily use of DFU for a long time; it was great to monitor the
number of versions very quickly. Each day, a batch job ran DFU to
search every disk volume for any file with version number greater than
15,000; the user and system manager were notified, and usually took
action on their own. I never made use of any of the features which
would modify anything on the disk volume, as DFU was unsupported. I
once wrote to Jurg, and he replied quickly with a suggestion for me,

I am not in a position to support this tool; but if I were, I would
rename it for x86 functions and only support read-only mode (perhaps
DFURO, although that sounds wonky). This is a great opportunity for
someone interested in the internals of the file system.
Carl
On Thu, Apr 6, 2023 at 6:30 AM Ian Miller via Info-vax
<info-vax@rbnsn.com> wrote:
>
> On Thursday, April 6, 2023 at 6:58:02 AM UTC+1, Jan-Erik Söderholm wrote:
> > Den 2023-04-05 kl. 15:29, skrev Arne Vajhøj:
> > > On 4/5/2023 9:21 AM, Dave Froble wrote:
> > >> On 4/5/2023 4:35 AM, Jan-Erik Söderholm wrote:
> > >>> Just heard a rumor that there is no plan for DFU on x86-64.
> > >>> Any comments on that?
> > >>
> > >> Perhaps the thought is that everyone is now using SSDs, and not so much
> > >> need for DFU?
> > >
> > > Many DFU features sounds relevant for SSD as well (just not defrag).
> > >
> > > And even for defrag then VSI has ported DFG to x86-64 per:
> > > https://vmssoftware.com/products/disk-file-optimizer/
> > >
> > > Arne
> > >
> > We (and the source where I heard this) only uses DFU for non-update
> > tasks. There are many nice search and report features in DFU. And
> > at least my source has a strict ban against using DFU for anything
> > that updates disk data.
> >
> > My source is a major VMS user in Sweden that is in the work of their
> > IA64 to x86-64 migration. They goes through all their 3-party tools
> > and DFU has been "red-flagged".
> >
> > My source wrote:
> >
> > "DFU is unfortunately flagged red. Its a freeware and the maintainer
> > is not interested in porting this to x86-64. We have asked VSI but
> > have not got any positive answer. They are probably fully occupied
> > with their own software, and there might be parts of DFU that VSI
> > might not want to take responsability for, like DEFRAGMENT, MODIFY,
> > UNDELETE and VERIFY".
> >
> > I have no idea if they actually have been in contact with the DFU
> > maintainer, or if that is hearsay. Or if they have got any other
> > reply from VSI apart from a "positive" one.
> >
> > Probably not a show-stopper for the x86-64 migration (I think they
> > definitely will migrate), but might need rewrite of a few routines.
> >
> > So, I guess the question is if there is someone else that would like
> > to pick up the DFU sources and try a x86 build...
>
> Such are the risks of relying on freeware maintained by one person even if it is a useful too like DFU. IIRC Jur saved DFU by taking it over from the original author and improving it. Perhaps it's time again.
> _______________________________________________
> Info-vax mailing list
> Info-vax@rbnsn.com
> http://rbnsn.com/mailman/listinfo/info-vax_rbnsn.com

--
www.comets.com

On 4/6/23 12:57 AM, Jan-Erik Söderholm wrote:

> So, I guess the question is if there is someone else that would like
> to pick up the DFU sources and try a x86 build...

And where would one pick them up? It says at

<https://www.digiater.nl/dfu.html>

"The sources are not available."

Den 2023-04-06 kl. 14:51, skrev Craig A. Berry:
> On 4/6/23 12:57 AM, Jan-Erik Söderholm wrote:
>
>> So, I guess the question is if there is someone else that would like
>> to pick up the DFU sources and try a x86 build...
>
> And where would one pick them up?  It says at
>
>   <https://www.digiater.nl/dfu.html>
>
> "The sources are not available."
>

You are right, that is an issue, of course.
And that was the same message when asked
directly a little more then a year ago.

On 4/6/2023 8:51 AM, Craig A. Berry wrote:
> On 4/6/23 12:57 AM, Jan-Erik Söderholm wrote:
>> So, I guess the question is if there is someone else that would like
>> to pick up the DFU sources and try a x86 build...
>
> And where would one pick them up?  It says at
>
>   <https://www.digiater.nl/dfu.html>
>
> "The sources are not available."

My guess is that at least some of the code is proprietary
DEC code and that it would require HPE approval
to release it as open source.

Arne

On 4/6/2023 6:23 AM, Ian Miller wrote:
> On Thursday, April 6, 2023 at 6:58:02 AM UTC+1, Jan-Erik Söderholm wrote:
>> So, I guess the question is if there is someone else that would like
>> to pick up the DFU sources and try a x86 build...
>
> Such are the risks of relying on freeware maintained by one person even if it is a useful too like DFU.

Such is the risk in life.

Oracle client is maintained by a 40 B$/yr 140000 employee
company. Still got dropped.

> IIRC Jur saved DFU by taking it over from the original author and improving it. Perhaps it's time again.

It would be nice if somebody could take over.

Even if the code could not be generally released then maybe someone
could get it under terms acceptable to all copyright owners.

Arne