a***@spenarnc.xs4all.nl
2024-05-03 09:59:40 UTC
I read the promotion of Docker. It tries to solve the problem:
"it works on my machine". Then it doesn't work on yours.
The correct solution - I think - is distributions. Debian goes to
great length to make sure that all programs cooperate.
Docker tries to pull in all possible influences in your machine
to generate a "package". Then it supposedly works.
Looking at a Forth compiler I see external influences:
- it works on a version of linux or windows. Those good folks
work hard that my program works the same on the next version.
- It observes a PATH : to find the program system wide.
Even this is not necessary, you can specify the full path.
What I do.
In ciforth there are no references to any configuration items,
not via environment variables, not via /etc files.
A library file is a necessity, but a reference to it is burned
into the executable during installation.
May one conclude that an elementary tool as a compiler, (and
say shells, utilities like dir etc.) should stay away from
this docker concept?
I see that there are several competing "package managers".
Instead of installing a program, you must start by
installing the behooved package manager before you can continue.
github invites you to select one of 6 possible packages:
Docker/ ApacheMaven / Nuget/Rubygems/npm/ Containers.
I fear for the future:
As the dust settles, and e.g. Nuget has won, you no longer
can run programs unless you pay monthly 10 euro's to Nuget
incorporated (student discounts possible.)
Ullrich Hofman has created a github archive of docker images
of forths, (including lina32 and lina64 for i86 linux. )
https://github.com/uho/docker-forth
What are the possibilities opened by this effort?
Groetjes Albert
"it works on my machine". Then it doesn't work on yours.
The correct solution - I think - is distributions. Debian goes to
great length to make sure that all programs cooperate.
Docker tries to pull in all possible influences in your machine
to generate a "package". Then it supposedly works.
Looking at a Forth compiler I see external influences:
- it works on a version of linux or windows. Those good folks
work hard that my program works the same on the next version.
- It observes a PATH : to find the program system wide.
Even this is not necessary, you can specify the full path.
What I do.
In ciforth there are no references to any configuration items,
not via environment variables, not via /etc files.
A library file is a necessity, but a reference to it is burned
into the executable during installation.
May one conclude that an elementary tool as a compiler, (and
say shells, utilities like dir etc.) should stay away from
this docker concept?
I see that there are several competing "package managers".
Instead of installing a program, you must start by
installing the behooved package manager before you can continue.
github invites you to select one of 6 possible packages:
Docker/ ApacheMaven / Nuget/Rubygems/npm/ Containers.
I fear for the future:
As the dust settles, and e.g. Nuget has won, you no longer
can run programs unless you pay monthly 10 euro's to Nuget
incorporated (student discounts possible.)
Ullrich Hofman has created a github archive of docker images
of forths, (including lina32 and lina64 for i86 linux. )
https://github.com/uho/docker-forth
What are the possibilities opened by this effort?
Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring. - the Wise from Antrim -
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring. - the Wise from Antrim -