VMS X86

[Wilhelm Greiner]

Moin,

ist zwar OT aber zur Info:
Es gibt ein aktuelles OpenVMS für x86.

"As an existing VMS Software Inc. Community Program member,
you are being granted access to the OpenVMS x86-64 E9.2-1 field test."

vmssoftware.com

Wilhelm

[cuby....@googlemail.com]

On Friday, April 14, 2023 at 3:15:01 AM UTC-4, Wilhelm Greiner wrote:
> Es gibt ein aktuelles OpenVMS für x86.
>
> "As an existing VMS Software Inc. Community Program member,
> you are being granted access to the OpenVMS x86-64 E9.2-1 field test."

Artikel dazu: https://virtuallyfun.com/2023/04/10/openvms-x86-finally-here/

- Michael

[Manfred Haertel]

Wilhelm Greiner schrieb:

> Es gibt ein aktuelles OpenVMS für x86.

Das gibt es aber schon seit eins, zwei Jahren.

Kommt trotzdem mindestens 25 Jahre zu spät.

--
Manfred Härtel, DB3HM mailto:Manfred...@rz-online.de
http://rz-home.de/mhaertel

[Dennis Grevenstein]

Manfred Haertel <Manfred...@rz-online.de> wrote:
>
> Das gibt es aber schon seit eins, zwei Jahren.

Aber ich glaube jetzt es ist es wirklich verfuegbar fuer normale
Menschen.

> Kommt trotzdem mindestens 25 Jahre zu spaet.

Ich frage mich tatsaechlich, welches Geschaeftsmodell dahintersteckt.
Das kann ja eigentlich nur noch durch irgendeine Drei-Buchstaben-
Organisation finanziert werden.

gruss,
Dennis

--
"I've seen things you people wouldn't believe. Attack ships on fire off the
shoulder of Orion. I watched C-beams glitter in the dark near the Tannhaeuser
gate. All those moments will be lost in time, like tears in rain."

[Kay Martinen]

Am 14.04.23 um 22:54 schrieb Dennis Grevenstein:

> Manfred Haertel <Manfred...@rz-online.de> wrote:
>>
>> Das gibt es aber schon seit eins, zwei Jahren.
>
> Aber ich glaube jetzt es ist es wirklich verfuegbar fuer normale
> Menschen.

Ich glaube manchmal die "Normalen" sind schon weitgehend ausgestorben.

>> Kommt trotzdem mindestens 25 Jahre zu spaet.
>
> Ich frage mich tatsaechlich, welches Geschaeftsmodell dahintersteckt.
> Das kann ja eigentlich nur noch durch irgendeine Drei-Buchstaben-
> Organisation finanziert werden.

Also... IBM?

SCNR. :)

Von NetBSD wird gern behauptet es liefe auf einem Toaster ebenso wie auf
einem Taschenrechner. Ist es so falsch an zu nehmen VMS nicht nur auf
dickem (Antikem?) Blech umsetzen zu wollen sondern auf der PC-Schiene
die ja seitdem mächtige Leistungssprünge machte?

Welche "Killer-App" gibt es die Interessenten zu einem PC VMS ziehen
könnte? Fortran, oder etwas größeres?

Oder kann es sein das den Drei-Buchstaben Jungs die Alte HW mit dem
Original langsam unterm Hintern verrottet?

Ｂｙｅ／
／Ｋａｙ

--
"Kann ein Wurstbrot die Welt retten?" :-)

[Dennis Grevenstein]

Kay Martinen <use...@martinen.de> wrote:
>
> Ich glaube manchmal die "Normalen" sind schon weitgehend ausgestorben.

Ich meinte vielmehr, dass sie es nun fuer die ganze Hobbyists
rausgeben. Das ist bestimmt auch schoen. In meiner Wahrnehmung
sterben vielmehr die alten Professionellen aus bzw. gehen halt
einfach in Rente.

> Von NetBSD wird gern behauptet es liefe auf einem Toaster ebenso wie auf
> einem Taschenrechner. Ist es so falsch an zu nehmen VMS nicht nur auf
> dickem (Antikem?) Blech umsetzen zu wollen sondern auf der PC-Schiene

> die ja seitdem maechtige Leistungsspruenge machte?

Das Problem ist ja weniger, dass VMS auf x86 gar keinen interessieren
wuerde. Ich frage mich nur, ob sich das finanziell lohnt.

> Welche "Killer-App" gibt es die Interessenten zu einem PC VMS ziehen

> koennte? Fortran, oder etwas groesseres?

Es gibt eigentlich keine Killer-Applikation.
Aber es besteht immer die Moeglichkeit, dass Leute Software ueber
Jahre auf VMS entwickelt und gepflegt haben und vielleicht features
von VMS wie cluster/Redundanz/etc. benutzen, die man nicht einfach
woanders nachbauen kann. Ein paar so Geschichten habe ich aus
Bereichen wie Industrie/Finanz/Infrastruktur mitbekommen. Aber die
Frage ist ja, ob es nicht einfach billiger ist, das mal neu auf einer
modernen Plattform zu entwickeln bzw. die ganz alten, unersetzbaren
Dinge halt zu emulieren.

> Oder kann es sein das den Drei-Buchstaben Jungs die Alte HW mit dem
> Original langsam unterm Hintern verrottet?

Moeglich.

[p...@pocnet.net]

Kay Martinen <use...@martinen.de> wrote:

>> Aber ich glaube jetzt es ist es wirklich verfuegbar fuer normale
>> Menschen.
>
> Ich glaube manchmal die "Normalen" sind schon weitgehend ausgestorben.

Das ist aber konträr zur wissenschaftlichen Definition von "normal". :-)

> Welche "Killer-App" gibt es die Interessenten zu einem PC VMS ziehen
> könnte? Fortran, oder etwas größeres?

"Man sagt", VMS sei ziemlich weit verbreitet im Mobilfunkbereich. Gerade
SMS-Handling würde weitestgehend über VMS-Maschinen abgewickelt.

Wie sehr das heute noch Gültigkeit hat, seit Whatsapp, ist die andere Frage.

> Oder kann es sein das den Drei-Buchstaben Jungs die Alte HW mit dem
> Original langsam unterm Hintern verrottet?

Das iszt definitiv der Fall. Der Itanium als Heilsbringer hat sich ja schon
recht bald als Totgeburt rausgestellt.

:wq! PoC

[p...@pocnet.net]

Dennis Grevenstein <dennis.gr...@gmail.com> wrote:

> Aber die Frage ist ja, ob es nicht einfach billiger ist, das mal neu auf
> einer modernen Plattform zu entwickeln bzw. die ganz alten, unersetzbaren
> Dinge halt zu emulieren.

Nein, ist es nicht. Sonst würde man das ja tun. Es geht immer nur um's Geld.

Die interessantere Frage für mich ist, wenn es darum geht, alten Code
weiterlaufen lassen zu können: Ist da dann ein "CPU"-Emulator drin, so wie das
Apple bei den PowerPCs eingebaut hatte?

Firmen gehen Pleite, Quellcode ist wech, Programm war kompiliert für VAXen,
aber nicht für Intel. Das sehe ich als das wahrscheinlichste Szenario.

:wq! PoC

[Clemens Schüller]

Servus!

PoC schrieb am 15. Apr. 2023 um 03:36:


> "Man sagt", VMS sei ziemlich weit verbreitet im Mobilfunkbereich. Gerade
> SMS-Handling würde weitestgehend über VMS-Maschinen abgewickelt.
>
> Wie sehr das heute noch Gültigkeit hat, seit Whatsapp, ist die andere Frage.

Vor X Jahren lief die Warenwirtschaft eines großen Möbelhändlers auf/unter
VMS, in den Abteilungen standen dann VT Terminals.

Ob es heute auch noch der Fall ist, weiß ich nicht.


--
LieGrü aus Graz, Clemens

[Eric Bruecklmeier]

Am 15.04.2023 um 08:32 schrieb Clemens Schüller:
> Servus!
>
> PoC schrieb am 15. Apr. 2023 um 03:36:
>
>
>> "Man sagt", VMS sei ziemlich weit verbreitet im Mobilfunkbereich. Gerade
>> SMS-Handling würde weitestgehend über VMS-Maschinen abgewickelt.
>>
>> Wie sehr das heute noch Gültigkeit hat, seit Whatsapp, ist die andere Frage.
>
> Vor X Jahren lief die Warenwirtschaft eines großen Möbelhändlers auf/unter
> VMS, in den Abteilungen standen dann VT Terminals.
>

Bei einem meiner Exarbeitgeber lief das ganze shop floor control system
auf DEC. Dabei war Produktion und Warenwirtschaft so eng verflochten (im
Laufe der Zeit gewachsten), daß mehrere Anläufe zur Migration, unter
Versenkung nicht unerheblicher Beträge, an der Komplexität scheiterten.
WIMRE wurde dann ein größerer Posten NOS Hardware besorgt und
vorgehalten. Ist aber jetzt auch schon wieder über 10 Jahre her - wie
sie das heute machen, weiß ich nicht.

[Alexander Schreiber]

Kay Martinen <use...@martinen.de> wrote:
> Am 14.04.23 um 22:54 schrieb Dennis Grevenstein:
>> Manfred Haertel <Manfred...@rz-online.de> wrote:
>>>
>>> Das gibt es aber schon seit eins, zwei Jahren.
>>
>> Aber ich glaube jetzt es ist es wirklich verfuegbar fuer normale
>> Menschen.
>
> Ich glaube manchmal die "Normalen" sind schon weitgehend ausgestorben.
>
>>> Kommt trotzdem mindestens 25 Jahre zu spaet.
>>
>> Ich frage mich tatsaechlich, welches Geschaeftsmodell dahintersteckt.
>> Das kann ja eigentlich nur noch durch irgendeine Drei-Buchstaben-
>> Organisation finanziert werden.
>
> Also... IBM?

Eher Firmen die seit VAX/Alpha Zeiten Wichtige Dinge (TM) auf VMS laufen
haben und wo der letzte Mitarbeiter, der das System detailliert genug
verstand um eine Portierung auf eine aktuelle Plattform zu ermöglichen
schon seit Jahren in Rente ist ;-)

Da heisst es dann: Entweder die Zähne zusammenbeissen und komplett neu
entwickeln auf aktueller Plattform (und hoffen, dass das auch funktioniert
und man nicht drei Dutzend kritische Sonderfälle die nur 1x/Jahr auftreten
vergessen hat) oder halt bei VMS bleiben, das ganze auf neue Hardware
heben und hoffen, dass man so das Problem bis zur eigenen Pensionierung
(oder Firmenwechsel) weiter ignorieren kann. ;-)

> SCNR. :)
>
> Von NetBSD wird gern behauptet es liefe auf einem Toaster ebenso wie auf
> einem Taschenrechner. Ist es so falsch an zu nehmen VMS nicht nur auf
> dickem (Antikem?) Blech umsetzen zu wollen sondern auf der PC-Schiene
> die ja seitdem mächtige Leistungssprünge machte?
>
> Welche "Killer-App" gibt es die Interessenten zu einem PC VMS ziehen
> könnte? Fortran, oder etwas größeres?

Ehern nicht. Migrationen von einer aktuellen Plattform auf VMS dürfte es kaum
geben.

> Oder kann es sein das den Drei-Buchstaben Jungs die Alte HW mit dem
> Original langsam unterm Hintern verrottet?

_Das_. Es gibt mittlerweile das Problem, das manche Organisationen sich
Ersatzteile und Reservehardware auf EBay erjagen müssen weil diese
seit 20+ Jahren nicht mehr hergestellt werden und auch die Lager der
"üblichen Verdächtigen" (schwer vergoldete Preise wegen 'Enterprise
Support', 'business continuity' usw.) zunehmend weniger hergeben.

Man liest sich,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison

[Alexander Schreiber]

p...@pocnet.net <p...@pocnet.net> wrote:
> Kay Martinen <use...@martinen.de> wrote:
>
>>> Aber ich glaube jetzt es ist es wirklich verfuegbar fuer normale
>>> Menschen.
>>
>> Ich glaube manchmal die "Normalen" sind schon weitgehend ausgestorben.
>
> Das ist aber konträr zur wissenschaftlichen Definition von "normal". :-)
>
>> Welche "Killer-App" gibt es die Interessenten zu einem PC VMS ziehen
>> könnte? Fortran, oder etwas größeres?
>
> "Man sagt", VMS sei ziemlich weit verbreitet im Mobilfunkbereich. Gerade
> SMS-Handling würde weitestgehend über VMS-Maschinen abgewickelt.

Wie mir ein Kollege aus dem Telco-Bereich vor Jahren mal erzählte:
So in den 1990er lief der ganze SMS Verkehr bei IIRC E Plus wohl über
einen einzelnen HP-UX Server (oder gar workstation). Bis dann jemand
merkte das a) SMS werden nicht abgerechnet (weil damals wenig Nutzung)
b) man kann IP über SMS machen. Die resultierende SMS-Flut hat die
einzelne Maschine wohl recht schnell geplättet und _sehr_ kurze Zeit
später kosteten SMS dann Geld.

> Wie sehr das heute noch Gültigkeit hat, seit Whatsapp, ist die andere Frage.

SMS ist nach wie vor in diversen kritischen Pfaden, so aus dem Kopf:
- 2nd Faktor für Kreditkartenzahlungen (jaja, ich weiss)
- Alarmnachrichten nachdem die grossen Pagernetze weg sind
- und IIRC als billiger, einfacher Kommunikationskanal für einen
ganzen Sack an Industrieautomatisierung (z.B. "Verkaufsautomat 1234
Coladosen leer", Alarmkanal für Objekt-Überwachungssystem, ...)

Gerade bei letzterem ist AFAIK noch ein ganzer Sack an Technik im
Einsatz der recht alt ist ("Ist doch noch gut!") und teilweise von
IP over GSM/3G/LTE/... noch nichts gehört hat (und teilweise das
gar nicht könnte - ein Bekannter hat vor vielen Jahren mal in Auftrags-
arbeit ein kleines Objektüberwachungssystem gebaut dessen Kern ein
Mikrocontroller mit IIRC 128 Byte RAM war - musste billig sein, also
nix IP Stack, aber SMS ging).

[Alexander Schreiber]

Dennis Grevenstein <dennis.gr...@gmail.com> wrote:
> Kay Martinen <use...@martinen.de> wrote:
>>
>> Ich glaube manchmal die "Normalen" sind schon weitgehend ausgestorben.
>
> Ich meinte vielmehr, dass sie es nun fuer die ganze Hobbyists
> rausgeben. Das ist bestimmt auch schoen. In meiner Wahrnehmung
> sterben vielmehr die alten Professionellen aus bzw. gehen halt
> einfach in Rente.
>
>> Von NetBSD wird gern behauptet es liefe auf einem Toaster ebenso wie auf
>> einem Taschenrechner. Ist es so falsch an zu nehmen VMS nicht nur auf
>> dickem (Antikem?) Blech umsetzen zu wollen sondern auf der PC-Schiene
>> die ja seitdem maechtige Leistungsspruenge machte?
>
> Das Problem ist ja weniger, dass VMS auf x86 gar keinen interessieren
> wuerde. Ich frage mich nur, ob sich das finanziell lohnt.

Offenbar schon - soweit ich weiss ist VSI keine Wohlfahrtsorganisation ;-)

>> Welche "Killer-App" gibt es die Interessenten zu einem PC VMS ziehen
>> koennte? Fortran, oder etwas groesseres?
>
> Es gibt eigentlich keine Killer-Applikation.
> Aber es besteht immer die Moeglichkeit, dass Leute Software ueber
> Jahre auf VMS entwickelt und gepflegt haben und vielleicht features
> von VMS wie cluster/Redundanz/etc. benutzen, die man nicht einfach
> woanders nachbauen kann. Ein paar so Geschichten habe ich aus
> Bereichen wie Industrie/Finanz/Infrastruktur mitbekommen. Aber die
> Frage ist ja, ob es nicht einfach billiger ist, das mal neu auf einer
> modernen Plattform zu entwickeln bzw. die ganz alten, unersetzbaren
> Dinge halt zu emulieren.

Ich glaube kaum, dass es Plattformaspekte sind, die aktuelle Nutzer
bei VMS halten - Clustering, Redundanz, ... kann man auch auf anderen,
aktuellen Plattformen haben, da gibt es genug Lösungen dafür die sich
auch durchaus bewährt haben.

Das Problem dürfte eher sein: Das sind Softwaresysteme, die über
Jahrzehnte gewachsen sind (wer aktuell VMS produktiv einsetzt, hat
damit kaum vor 5 Jahren angefangen). Da steckt oftmal viel Komplexität
drin, die sich mit der Zeit entwickelt hat. Code, der spezielle Sonder-
fälle bedient, die maximal einmal im Jahr bei Vollmond und Frostwetter
vorkommen, aber richtig teuer werden wenn es schiefläuft. Diverse
komplexe Geschäftslogik, die im aktuellen System "einfach so" funktioniert,
aber es gibt kein Design dafür, der Sourcecode ist ... kein Glanzstück
an Lesbarkeit und der letzte Mitarbeiter, der noch wusste, _wieso_
genau _dort_ eine spezielle Sonderlösung steht ist mittlerweile entweder
in Rente oder auf einem anderen Kontinent oder beides.

Sowas komplett neu auf einer aktuellen Plattform zu implementieren ist
bestenfalls ziemlich komplex. Kann man machen, aber die Chance, dass
man irgendwelche Sonderfälle übersieht die einen dann recht teuer
beissen ist praktisch 100%. Wenn man Glück hat, wird irgendwann die
Firma so umgebaut, dass man die alte Software beerdigen und neu
anfangen kann ;-)

Und der Standard an "software engineering" der da oft üblich ist, hilft
da gar nicht: design docs? Haha. test coverage? Bahnhof. Kann man teilweise
schon froh sein wenn Versionverwaltung nicht mit "Kollege tut bei
Gelegenheit mal den aktuellen Quelltext in ein Zipfile auf dem Server"
"erledigt" wird.

[Dennis Grevenstein]

Alexander Schreiber <a...@usenet.thangorodrim.de> wrote:
>
> Ich glaube kaum, dass es Plattformaspekte sind, die aktuelle Nutzer
> bei VMS halten - Clustering, Redundanz, ... kann man auch auf anderen,

> aktuellen Plattformen haben, da gibt es genug Loesungen dafuer die sich
> auch durchaus bewaehrt haben.

sicherlich. Ich meinte eher, ob man das so ersetzen kann, wenn die
Anwendung das selbst integriert.

> Das Problem duerfte eher sein: Das sind Softwaresysteme, die ueber

> Jahrzehnte gewachsen sind (wer aktuell VMS produktiv einsetzt, hat
> damit kaum vor 5 Jahren angefangen).

Ja, genau. An sowas wuerde ich auch denken.
Nur ueberleg Dir mal, wie software entwickeln unter VMS funktioniert.
VMS ist so eine der Plattformen, wo "we just typed make" praktisch
niemals vorkommt. Bei den bisherigen CPU-Wechseln VAX->Alpha und
Alpha->IA64 ist jeweils sehr viel software verloren gegangen und
es hat ewig gedauert bis die Leute ihr Zeugs gluecklich portiert
hatten. Das steht bei einem neuen Wechsel wieder an.
Demgegenueber kann man die alten Sachen mittlerweile emulieren.

> Und der Standard an "software engineering" der da oft ueblich ist, hilft

> da gar nicht: design docs? Haha. test coverage? Bahnhof. Kann man teilweise
> schon froh sein wenn Versionverwaltung nicht mit "Kollege tut bei
> Gelegenheit mal den aktuellen Quelltext in ein Zipfile auf dem Server"
> "erledigt" wird.

mag ja alles sein. Ich frage mich halt nach der Verhaeltnismaessigkeit.
Wie kann es sein, dass man gleichzeitig viel Geld sparen will, aber
trotzdem das Geld ausgeben will, software auf einer teuren Exotenplattform
laufen zu lassen und am Leben zu erhalten? Dazu kommt, dass die
Portierung und Pflege von VMS selbst ja auch mit finanziert werden
muss. Wie kann es sein, dass man gleichzeitig keine Entwickler-Ressourcen
hat, um code neu zu entwickeln, aber trotzdem die Ressourcen hat, um
den legacy code auf eine neue CPU Architektur zu portieren?
Das ist schliesslich auch nicht so wie wenn ich versuche ein Stueck
GNU zu portieren und wenn es ohne error compiliert, dann bin ich
fertig und der Rest geht mit Prinzip Hoffnung.

VMS und die ganzen klassischen, proprietaeren Unix System waren
immer querfinanziert, weil sie nur auf der eigenen Hardware liefen.
Wer VMS wollte, musste halt die Hardware von DEC kaufen. Wenn man
das nun anders aufzieht und VMS sich selbst ueber Lizenzen und
support finanzieren muss, dann aendert sich die gesamte Grundlage.

[Dennis Grevenstein]

p...@pocnet.net wrote:
>
> Die interessantere Frage fuer mich ist, wenn es darum geht, alten Code
> weiterlaufen lassen zu koennen: Ist da dann ein "CPU"-Emulator drin,

> so wie das Apple bei den PowerPCs eingebaut hatte?

nein.

> Firmen gehen Pleite, Quellcode ist wech, Programm war kompiliert fuer VAXen,
> aber nicht fuer Intel. Das sehe ich als das wahrscheinlichste Szenario.

Dann brauchst Du immer noch eine VAX, egal ob als Original oder als
Emulator. Emulieren ist heute viel schneller.
VMS ist halt kein mainframe.

[Dennis Grevenstein]

p...@pocnet.net wrote:
>
> Das iszt definitiv der Fall. Der Itanium als Heilsbringer hat sich ja schon
> recht bald als Totgeburt rausgestellt.

20 Jahre Lebenszeit und durchaus brauchbare Hardware wuerde ich nicht
unbedingt als Totgeburt bezeichnen. Ob es eine kluge Plattformwahl
war, ist ja nochmal eine ganz andere Frage. Uberleg Dir nur mal zum
Vergleich, dass die erste VAX 1979 rauskam und 15 Jahre spaeter war
VAX als Plattform so veraltet, dass nur noch die Verzweifelten neue
VAXen gekauft haben. Daran gemessen war Itanium gar nicht so schlecht.
Man haette halt vor 10 Jahren eine Nachfolgeplattform fuer VMS announcen
und entwickeln sollen.

[Kay Martinen]

Am 15.04.23 um 12:53 schrieb Alexander Schreiber:

> Kay Martinen <use...@martinen.de> wrote:
>> Am 14.04.23 um 22:54 schrieb Dennis Grevenstein:

>>> Ich frage mich tatsaechlich, welches Geschaeftsmodell dahintersteckt.
>>> Das kann ja eigentlich nur noch durch irgendeine Drei-Buchstaben-
>>> Organisation finanziert werden.
>>
>> Also... IBM?
>
> Eher Firmen die seit VAX/Alpha Zeiten Wichtige Dinge (TM) auf VMS laufen
> haben und wo der letzte Mitarbeiter, der das System detailliert genug
> verstand um eine Portierung auf eine aktuelle Plattform zu ermöglichen
> schon seit Jahren in Rente ist ;-)

Also wie üblich jene die

- den Trend verschlafen haben.
- den Schuß nicht hörten.
- Geld sparen wollten um des Geld Verdienens wegen.

Insgesamt also welche bei denen sich das Mitleid in Grenzen hielte oder?

> Da heisst es dann: Entweder die Zähne zusammenbeissen und komplett neu
> entwickeln auf aktueller Plattform (und hoffen, dass das auch funktioniert
> und man nicht drei Dutzend kritische Sonderfälle die nur 1x/Jahr auftreten
> vergessen hat) oder halt bei VMS bleiben, das ganze auf neue Hardware
> heben und hoffen, dass man so das Problem bis zur eigenen Pensionierung
> (oder Firmenwechsel) weiter ignorieren kann. ;-)

Ja aber macht man da nicht auch ein Riesen Faß auf wenn man versucht
"Hochsprachen" Quellkode von VAX/VMS auf x86/VMS zu portieren? Gut, man
muß den altbewährten Compiler (Fortran? Algol?) sowieso zuerst auf die
neue Maschine jagen und hoffen das er 1:1 das funktionsgleiche Ergebnis
liefern würde. Und dann muß man halt seine eigentlichen Mission-critical
Apps da durch jagen. Und dann erneut hoffen das nun das x86 Compilat
genau das gleiche auf die gleiche Weise tut wie das auf der alten VAX
die man ersetzen will.

Und wo genau ist da dann der unterschied dazu den alten Compiler z.b.
nativ auf einem x64-Linux zu übersetzen und den dann dort die programme
neu übersetzen zu lassen?

Vermutung: Es kann dann mehr um die interaktion mit dem OS gehen also
SysCalls o.ä. die anders reagieren als VMS. Ist dies dann nicht eine
einmalige Anpassung die man ggf. auch nur ein mal als
"Übersetzungshilfe" im Compiler einbauen könnte?

>> Welche "Killer-App" gibt es die Interessenten zu einem PC VMS ziehen
>> könnte? Fortran, oder etwas größeres?
>
> Ehern nicht. Migrationen von einer aktuellen Plattform auf VMS dürfte es kaum
> geben.

Das habe ich auch eher nicht wirklich angenommen. Bestenfalls privates
Retrointeresse der hier mitlesenden. Ich meinte schon das Gegenteil.
Ersatz alter Systeme statt "Rückkehr vom neuen zum Alten".

>> Oder kann es sein das den Drei-Buchstaben Jungs die Alte HW mit dem
>> Original langsam unterm Hintern verrottet?
>
> _Das_. Es gibt mittlerweile das Problem, das manche Organisationen sich
> Ersatzteile und Reservehardware auf EBay erjagen müssen weil diese
> seit 20+ Jahren nicht mehr hergestellt werden und auch die Lager der
> "üblichen Verdächtigen" (schwer vergoldete Preise wegen 'Enterprise
> Support', 'business continuity' usw.) zunehmend weniger hergeben.

Hmm. Du meinst also das alle die noch so alte Geräte im Keller, Lager,
Museum hätten damit rechnen müßten das ihnen eine ungenannte
Organisation "Ein Angebot macht das sie nicht ablehnen könnten"?

Kann schon Mist sein wenn man "den Schuß nicht gehört hat" oder? ;-)

Es gibt doch auch vermehrt Bestrebungen sich vordergründig von
China-Exporten unabhängiger zu machen durch Rückverlagerung der
Produktion im eigenen Lande (Speziell USA). Natürlich zu höheren Preisen
aber bedenkt man das die Exporte wohl vor allem darum billiger sind weil
A: Billige Arbeitskräfte und B: Günstiger Massentransport per Container
dafür sorgen. Ändert nix an A & B könnte in großem Volumen aber
Seiteneffekte haben wenn es viele (Natürlich Staatlich alimentiert)
Durchführten.

Endpunkt könnte der Niedergang der Exporte sein, Massenarbeitslosigkeit
in China, und zu was der führen mag weiß keiner...

O-FeFe-J: "Hat bestimmt die CIA raus gefunden. Die finden alles raus..." :-)

[p...@pocnet.net]

Dennis Grevenstein <dennis.gr...@gmail.com> wrote:

>> Die interessantere Frage fuer mich ist, wenn es darum geht, alten Code
>> weiterlaufen lassen zu koennen: Ist da dann ein "CPU"-Emulator drin, so wie
>> das Apple bei den PowerPCs eingebaut hatte?
>
> nein.

Dann scheidet das wohl aus.

>> Firmen gehen Pleite, Quellcode ist wech, Programm war kompiliert fuer VAXen,
>> aber nicht fuer Intel. Das sehe ich als das wahrscheinlichste Szenario.
>
> Dann brauchst Du immer noch eine VAX, egal ob als Original oder als
> Emulator. Emulieren ist heute viel schneller.

Gibt es denn kommerzielle Emulatoren? Meien Erfahrungen mit Netzwerk vs. SimH
vor einigen Jahren waren nicht so prickelnd.

> VMS ist halt kein mainframe.

Was genau meinst Du damit?

:wq! PoC

[p...@pocnet.net]

Alexander Schreiber <a...@usenet.thangorodrim.de> wrote:

> Wie mir ein Kollege aus dem Telco-Bereich vor Jahren mal erzählte: So in den
> 1990er lief der ganze SMS Verkehr bei IIRC E Plus wohl über einen einzelnen
> HP-UX Server (oder gar workstation). Bis dann jemand merkte das a) SMS
> werden nicht abgerechnet (weil damals wenig Nutzung) b) man kann IP über SMS
> machen. Die resultierende SMS-Flut hat die einzelne Maschine wohl recht
> schnell geplättet und _sehr_ kurze Zeit später kosteten SMS dann Geld.

Interessanter Einblick!

>> Wie sehr das heute noch Gültigkeit hat, seit Whatsapp, ist die andere Frage.
>
> SMS ist nach wie vor in diversen kritischen Pfaden, so aus dem Kopf:
> - 2nd Faktor für Kreditkartenzahlungen (jaja, ich weiss)
> - Alarmnachrichten nachdem die grossen Pagernetze weg sind
> - und IIRC als billiger, einfacher Kommunikationskanal für einen
> ganzen Sack an Industrieautomatisierung (z.B. "Verkaufsautomat 1234
> Coladosen leer", Alarmkanal für Objekt-Überwachungssystem, ...)

Ja, nur ist das alles kein Massengeschäft mehr. Ich vermute, dass da einiges
rückgebaut wurde und der Restbestand wird irgendwie am Leben gehalten.

:wq! PoC

[p...@pocnet.net]

Dennis Grevenstein <dennis.gr...@gmail.com> wrote:

> mag ja alles sein. Ich frage mich halt nach der Verhaeltnismaessigkeit.
> Wie kann es sein, dass man gleichzeitig viel Geld sparen will, aber
> trotzdem das Geld ausgeben will, software auf einer teuren Exotenplattform
> laufen zu lassen und am Leben zu erhalten?

Siehe die vorherige Erklärung zu gewachsener Software und Corner-Cases die
einmal im Jahrhundert auftreten können.

Alter Quellcode ist im Regelfall unwartbar komplex, weil Aufräumen und
Dokumentation kostet Zeit und damit Geld.

:wq! PoC

[Gerald E¡scher]

Dennis Grevenstein schrieb am 15/4/2023 15:50:

> Man haette halt vor 10 Jahren eine Nachfolgeplattform fuer VMS announcen
> und entwickeln sollen.

Blöderweise hat sich Micro$oft anfang der 90er den Chef-Entwickler samt
Mannschaft gekrallt, die dann VMS zur eNTe gemacht haben.
Vor 10 Jahren war DEC längst im Besitz von HP. Ich meine nicht, dass die
noch großes Interesse an VMS hatten.

--
Gerald

[Michael Kraemer @ home]

Kay Martinen wrote:

>
> Welche "Killer-App" gibt es die Interessenten zu einem PC VMS ziehen
> könnte? Fortran, oder etwas größeres?

Keine.
Verwunderlich auch, dass, jedenfalls wenn man den Diskussionen auf c.o.v folgt,
so ziemlich alles, was einst VMS originaer von der Konkurrenz unterschied,
rausfliegt bzw rausfliegen sollte und durch irgendwas aus der Linux/UNIX Welt
ersetzt wird.
Sogar ein Insider wie S.Hofmann laesst an VMS eigentlich kein gutes Haar mehr.

Wahrscheinlich bleibt uebrig, was man schon immer gehasst hat:
Filenamen mit eckigen Klammern und Semikolons.

Da fragt man sich schon, wozu der Aufwand, warum nicht gleich Linux.
An die Superspezialfaelle, die man mit heutigen Businessloesungen von der Stange
nicht abdecken koennte, glaube ich nicht.

> Oder kann es sein das den Drei-Buchstaben Jungs die Alte HW mit dem
> Original langsam unterm Hintern verrottet?

Der Ruf nach der US-Kavallerie als Retter ist in letzter Zeit ziemlich leise
geworden.

[Gerrit Heitsch]

On 4/15/23 18:42, Gerald E¡scher wrote:
> Dennis Grevenstein schrieb am 15/4/2023 15:50:
>
>> Man haette halt vor 10 Jahren eine Nachfolgeplattform fuer VMS announcen
>> und entwickeln sollen.
>
> Blöderweise hat sich Micro$oft anfang der 90er den Chef-Entwickler samt
> Mannschaft gekrallt, die dann VMS zur eNTe gemacht haben.

Und der hat ein paar sehr merkwürdige Dinger implementiert. Wie z.B. das
man unter Windows eine in Benutzung befindliche Datei nicht löschen oder
überschreiben kann. Was im täglichen Betrieb Ärger macht und
Systemupdates unnötig kompliziert.

Gerrit

[Dennis Grevenstein]

Michael Kraemer @ home <M.Kr...@gsi.de> wrote:
>
> Verwunderlich auch, dass, jedenfalls wenn man den Diskussionen auf c.o.v folgt,
> so ziemlich alles, was einst VMS originaer von der Konkurrenz unterschied,
> rausfliegt bzw rausfliegen sollte und durch irgendwas aus der Linux/UNIX Welt
> ersetzt wird.

c.o.v. ist halt auch ein seltsamer Ort im Internet.

>> Oder kann es sein das den Drei-Buchstaben Jungs die Alte HW mit dem
>> Original langsam unterm Hintern verrottet?
>
> Der Ruf nach der US-Kavallerie als Retter ist in letzter Zeit ziemlich leise
> geworden.

Irgendwer muss die show ja bezahlen.
VMS wird ja seit 30 Jahren totgesagt. Meine persönliche Wahrnehmung ist
sogar, dass da ein Stück Wahrheit dran ist. VMS hat immer weniger Nutzer
und diese Nutzer haben immer weniger VMS im Einsatz. Aus einem riesigen
VAXcluster wurden erst ein paar Alphas und dann standen da irgendwann
ein, zwei Itaniums. Und das geht halt so weiter. So ziemlich jede
Anwendung (von denen es nicht viele gibt) lässt sich mit einer modernen
rackmount box erledigen. Stellst Du zwei hin, hast Du das redundant
und mehr power als jede VAX, Alpha oder Itanium.

Ich glaube das bestimmt, dass da draussen Leute VMS im Einsatz haben,
um SMSe zu sortieren oder ihre Pipeline zu steuern, aber wieviele
Anwendungen, Lizenzen und Supportverträge sind das denn am Ende des
Tages? Vor dem Hintergrund halte ich es für einigermaßen plausibel,
dass es da irgendwen gibt, der VMS im Einsatz hat und vielleicht ohne
VMS in seinem Bunker nicht mehr das Licht ein- und ausschalten könnte
und daher motiviert ist, die show für alle zu bezahlen. Also jetzt
schon, im Hintergrund, ohne dass es alle mitbekommen.

[Stefan Möding]

Gerrit Heitsch <ger...@laosinh.s.bawue.de> writes:

> Und der hat ein paar sehr merkwürdige Dinger implementiert. Wie z.B. das man
> unter Windows eine in Benutzung befindliche Datei nicht löschen oder
> überschreiben kann. Was im täglichen Betrieb Ärger macht und Systemupdates
> unnötig kompliziert.

ja, weil man beim Filesystem unbedingt rückwärtskompatibel bleiben
musste... VMS hat da ja eine schöne Versionierung der Files, womit
problemlos eine Kopie angelegt werden konnte und die alte Version
weiterhin existiert.

Unter Unix kann man eine (geöffnete) Datei löschen und der Plattenplatz
wird nicht freigegeben. Das versteht auch nicht jeder.

--
Stefan

[Gerrit Heitsch]

Für mich eigentlich klar... Wer sie offen hat, der kann sie noch
lesen/schreiben. Für alle anderen ist sie weg.

Oder überschreiben. Wer die alte Datei offen hat bekommt den alten
Inhalt. Sie verschwindet erst dann, wenn der letzte Benutzer sie
freigegeben hat. Wer sie nicht offen hatte bekommt den neuen Inhalt.


Gerrit

[Michael Kraemer @ home]

Der Einwand geht wohl eher dahin, dass man etwas loescht
und trotzdem nicht mehr Platz hat.
Versteh ich auch nicht immer auf Anhieb.

[Gerrit Heitsch]

Ist doch simpel. Den Platz hat noch jemand in Benutzung. Finde raus wer
das ist, und schon ist das Problem gelöst.

Das geht aber noch besser. Stell dir vor ein Prozess öffnet ein Logfile
und löscht es sofort. Dann kann er dir die Platte mit dem Output füllen
ohne das du die fragliche Datei finden kannst.

Gerrit

[Gerrit Heitsch]

On 4/15/23 20:27, Stefan Ram wrote:
> Gerrit Heitsch <ger...@laosinh.s.bawue.de> writes:
>> Für mich eigentlich klar... Wer sie offen hat, der kann sie noch
>> lesen/schreiben. Für alle anderen ist sie weg.
>

> Unter UNIX entfernt "rm" WIMRE nur Einträge in Verzeichnissen, aber
> keine Dateien. Eine Datei wird entfernt, wenn es keine Verweise
> mehr auf sie gibt. Solche Verweise können Verzeichniseinträge
> sein, aber auch Prozesse, welche sie in Benutzung haben.
>
> Für Windows gibt es Zusatzprogramme, die es erlauben, Dateien
> zu entsperren, so daß man sie dann löschen kann, selbst wenn
> Prozesse sie noch in Verwendung haben.

Mag sein, gehören aber nicht zum Lieferumfang und sind deshalb mit
Vorsicht zu geniessen. Die Prozesse, denen man die Datei unter dem
Hintern wegzieht könnten das übelnehmen.

Gerrit

[Diedrich Ehlerding]

Kay Martinen meinte:

>> Eher Firmen die seit VAX/Alpha Zeiten Wichtige Dinge (TM) auf VMS
>> laufen haben und wo der letzte Mitarbeiter, der das System
>> detailliert genug verstand um eine Portierung auf eine aktuelle
>> Plattform zu ermöglichen schon seit Jahren in Rente ist ;-)
>
> Also wie üblich jene die
>
> - den Trend verschlafen haben.
> - den Schuß nicht hörten.
> - Geld sparen wollten um des Geld Verdienens wegen.

Insbesondere diejenigen Firmen, deren IT-Verantwortliche eh nur einen 5-
Jahres-Vertrag hatten, der jedes Jahr einen dicken Bonus beinhaltete -
aber nur dann, wenn die Kostenstelle "IT" nicht etwa dicker wurde!

Diese IT-Verantwortliche haben abkassiert, wussten vermutlich sehr gut,
dass da eine Zeitbombe tickte - aber eben erst nach Ablauf ihres
Vertrags platzen würde. Und deshalb haben sie dann rechtzeitig den
Absprung auf ein anderes Unternehmen geschafft. Hätten sie nämlich
rechtzeitig damit begonnen, ihre Systeme auf aktuelle Hardware zu
portieren, hätte das viel Zeit und Geld gekostet, und der Bonus wäre
flöten gewesen - "nach mir die Sinbtflut, soll sich doch mein nachfolger
damit unbeliebt machen" ...

>
> Insgesamt also welche bei denen sich das Mitleid in Grenzen hielte

+1
--
gpg-Key (DSA 1024) D36AD663E6DB91A4
fingerprint = 2983 4D54 E00B 8483 B5B8 C7D1 D36A D663 E6DB 91A4
HTML-Mail wird ungeleſen entſorgt.

[Gerrit Heitsch]

On 4/15/23 20:39, Diedrich Ehlerding wrote:
> Kay Martinen meinte:
>
>>> Eher Firmen die seit VAX/Alpha Zeiten Wichtige Dinge (TM) auf VMS
>>> laufen haben und wo der letzte Mitarbeiter, der das System
>>> detailliert genug verstand um eine Portierung auf eine aktuelle
>>> Plattform zu ermöglichen schon seit Jahren in Rente ist ;-)
>>
>> Also wie üblich jene die
>>
>> - den Trend verschlafen haben.
>> - den Schuß nicht hörten.
>> - Geld sparen wollten um des Geld Verdienens wegen.
>
> Insbesondere diejenigen Firmen, deren IT-Verantwortliche eh nur einen 5-
> Jahres-Vertrag hatten, der jedes Jahr einen dicken Bonus beinhaltete -
> aber nur dann, wenn die Kostenstelle "IT" nicht etwa dicker wurde!

Man kann in der IT eine ganze Zeit eine Menge einsparen. Aber die
Rechnung kommt irgendwann.

> Diese IT-Verantwortliche haben abkassiert, wussten vermutlich sehr gut,
> dass da eine Zeitbombe tickte - aber eben erst nach Ablauf ihres
> Vertrags platzen würde. Und deshalb haben sie dann rechtzeitig den
> Absprung auf ein anderes Unternehmen geschafft. Hätten sie nämlich
> rechtzeitig damit begonnen, ihre Systeme auf aktuelle Hardware zu
> portieren, hätte das viel Zeit und Geld gekostet, und der Bonus wäre
> flöten gewesen - "nach mir die Sinbtflut, soll sich doch mein nachfolger
> damit unbeliebt machen" ...

Tja, wenn man falsche Anreize setzt muss man sich nicht wundern wenn
nach denen gelebt wird.

Gerrit

[Enrik Berkhan]

Gerrit Heitsch <ger...@laosinh.s.bawue.de> wrote:
> Ist doch simpel. Den Platz hat noch jemand in Benutzung. Finde raus wer
> das ist, und schon ist das Problem gelöst.

Noch simpler: unter Unix löscht man keine Dateien, sondern deren Namen.

Wenn alle Namen weg sind, kann man die Datei nicht mehr öffnen, aber
durchaus noch offen haben.

Wenn alle Namen weg sind und kein Prozess die Datei mehr offen hat, ist
sie weg.

(Es gibt so modernes Zeugs wie /proc/<pid>/fd/ unter Linux etc., das
wiederum für jede offene Datei einen Namen erzeugt, geht aber trotzdem
...)

Gruß,
Enrik

[Hanno Foest]

Am 15.04.23 um 13:34 schrieb Alexander Schreiber:

> Wie mir ein Kollege aus dem Telco-Bereich vor Jahren mal erzählte:
> So in den 1990er lief der ganze SMS Verkehr bei IIRC E Plus wohl über
> einen einzelnen HP-UX Server (oder gar workstation). Bis dann jemand
> merkte das a) SMS werden nicht abgerechnet (weil damals wenig Nutzung)
> b) man kann IP über SMS machen. Die resultierende SMS-Flut hat die
> einzelne Maschine wohl recht schnell geplättet und _sehr_ kurze Zeit
> später kosteten SMS dann Geld.

Die Geschichte kenne ich etwas anders:

--- cut ---
From: Andreas Bogk <and...@andreas.org>
Newsgroups: de.alt.sysadmin.recovery
Subject: Re: Jetzt seid ihr zu weit gegangen.
Date: 05 Mar 2002 17:33:10 +0000
Message-ID: <87sn7e3...@andreas.org>

Gerd Knorr <kra...@bytesex.org> writes:

> > SMS boomte auch schon mal 1995. Als es noch umsonst war, und man mit
> > einem Mobiltelefon und einem Linux-Hobel mit ein wenig perl noch
> > selber seine Dienste stricken konnte, ohne arm zu werden.
> uucp over sms?

Wäre problemlos gegangen, ja. Aber bedenke die Bandbreiten, mit dem
2110 haben wir am Tag 30000 SMSen verschicken können, also insgesamt
4.8 MB.

Ein Penner mit einem Wordfile hätte dir also mal eben 2 Tage die
Anbindung plattgemacht. Nee, mit der Bandbreite konnte man sinnvollere
Dinge tun.

Beliebt waren zum Beispiel Mailinglisten, vor allem "bvg" als
Informationssystem für Schwarzfahrer über den Aufenthaltsort der
Kontrolleure ("u2 nollendorfpl ri westen, 3 ältere Typen in
Lederjacken"), oder auch "blitzer" als Radarfrühwarnsystem für den
automobilen Teil der Bevölkerung. Prima war auch das TV-Programm, und
der Prüfziffernkalkulator für Kreditkarten. Oder der reverse-lookup
Telefonnummer nach Namen.

Leider haben wir damit eine arme HP, die sich bei e-Plus mit dem
Betrieb der SMSC-Software abmühte, vollständig in die Knie
gezwungen. Und anstatt da einen anständigen Computer mit richtiger
Software hinzustellen, und das ganze als Marketingaktion zu begreifen,
hat man sich entschlossen, lieber SMS-Gebühren einzuführen. Daraufhin
mußten wir den Kram abschalten, und die alte HP-Möhre hat's wieder
getan, und sie hatten das Investment gespart.

Daß das jetzt wieder so boomt, war nicht beabsichtigt. Da kamen halt
plötzlich große Mengen Geld an, und sie mußten sich damit
herumschlagen.

Tja, ich fürchte, jetzt ist es herausgekommen: wir sind schuld an den
SMS-Gebühren. Sorry Jungs.

Gruss Andreas
--- cut ---

Hanno

--
The modern conservative is engaged in one of man's oldest exercises in
moral philosophy; that is, the search for a superior moral justification
for selfishness.
- John Kenneth Galbraith

[Alexander Schreiber]

Kay Martinen <use...@martinen.de> wrote:
> Am 15.04.23 um 12:53 schrieb Alexander Schreiber:
>> Kay Martinen <use...@martinen.de> wrote:
>>> Am 14.04.23 um 22:54 schrieb Dennis Grevenstein:
>
>>>> Ich frage mich tatsaechlich, welches Geschaeftsmodell dahintersteckt.
>>>> Das kann ja eigentlich nur noch durch irgendeine Drei-Buchstaben-
>>>> Organisation finanziert werden.
>>>
>>> Also... IBM?
>>
>> Eher Firmen die seit VAX/Alpha Zeiten Wichtige Dinge (TM) auf VMS laufen
>> haben und wo der letzte Mitarbeiter, der das System detailliert genug
>> verstand um eine Portierung auf eine aktuelle Plattform zu ermöglichen
>> schon seit Jahren in Rente ist ;-)
>
> Also wie üblich jene die
>
> - den Trend verschlafen haben.
> - den Schuß nicht hörten.
> - Geld sparen wollten um des Geld Verdienens wegen.
>
> Insgesamt also welche bei denen sich das Mitleid in Grenzen hielte oder?

Sagen wir mal so: Ich bin froh, das dies ein Problem Anderer Leute(TM)
ist.

>> Da heisst es dann: Entweder die Zähne zusammenbeissen und komplett neu
>> entwickeln auf aktueller Plattform (und hoffen, dass das auch funktioniert
>> und man nicht drei Dutzend kritische Sonderfälle die nur 1x/Jahr auftreten
>> vergessen hat) oder halt bei VMS bleiben, das ganze auf neue Hardware
>> heben und hoffen, dass man so das Problem bis zur eigenen Pensionierung
>> (oder Firmenwechsel) weiter ignorieren kann. ;-)
>
> Ja aber macht man da nicht auch ein Riesen Faß auf wenn man versucht
> "Hochsprachen" Quellkode von VAX/VMS auf x86/VMS zu portieren? Gut, man
> muß den altbewährten Compiler (Fortran? Algol?) sowieso zuerst auf die

Eh, da erwarte eher keine bis minimale Probleme, sobald die Compiler
auf der neuen Architektur stabil sind (und dafür ist VSI zuständig).
Ich habe hier z.B. NetBSD auf 4 Systemarchitekturen am laufen:
- i386
- amd64
- sparc64
- aarch64
und die Platform macht fast keinen Unterschied (ok, sparc64 mag unaligned
loads/stores nicht und mault, wo es bei x86 "nur" Performance kostet)
und es läuft (je nach Einsatzzweck der Maschine) auch überall mehr oder
weniger die gleiche Software, ohne platform specific hacks.

> neue Maschine jagen und hoffen das er 1:1 das funktionsgleiche Ergebnis
> liefern würde. Und dann muß man halt seine eigentlichen Mission-critical
> Apps da durch jagen. Und dann erneut hoffen das nun das x86 Compilat
> genau das gleiche auf die gleiche Weise tut wie das auf der alten VAX
> die man ersetzen will.
>
> Und wo genau ist da dann der unterschied dazu den alten Compiler z.b.
> nativ auf einem x64-Linux zu übersetzen und den dann dort die programme
> neu übersetzen zu lassen?

VMS != Linux und die VMS APIs schlagen teilweise recht sichtbar im
Quellcode auf. Und das ist nicht nur "ein paar API Details sind anders"
wie z.B. zwischen NetBSD und Linux, sondern: da gibt es ganze APIs, die
es nur auf einer Seite gibt und es gibt _erhebliche_ Unterschiede in
den Systemkonzepten. File-I/O ist so ein Beispiel: Die ganzen Unixe
machen da nur "Dateien sind eine unstrukturierte Reihenfolge von Bytes,
allfällige Strukturen sind Applikationsproblem" - VMS hat datensatz-
basierten I/O in den Systembibliotheken als Standard. Prozesse sind
unter VMS eher teuer, also hat man typischerweise schwergewichtige
Prozesse die vieles machen - Prozesse (und fork() insbesondere) sind
unter Unix im Allgemeinen und gerade unter Linux im Besonderen
super billig, das beeinflusst Designentscheidungen. Alleine die
Kombination aus fork(2) und pipe(2) macht Dinge möglich, die auf
anderen Plattformen so nicht üblich oder gar machbar sind.

> Vermutung: Es kann dann mehr um die interaktion mit dem OS gehen also
> SysCalls o.ä. die anders reagieren als VMS. Ist dies dann nicht eine
> einmalige Anpassung die man ggf. auch nur ein mal als
> "Übersetzungshilfe" im Compiler einbauen könnte?

Egal was die neue Zielplattform ist, ob Linux oder meinetwegen Windows
(damit cryptolocker Kram endlich eine Chance hat), ein ganz wichtiges
Hindernis sind die ganz anderen System APIs. Ja, das kann man im Prinzip
mit einer Abstraktionsschicht mit entsprechend geschrieben Bibliotheken
bis zu einem gewissen Grad lösen, aber: das bedingt ein Entwicklerteam
das _sowohl_ die Zielplattform als auch VMS auf der Ebene der System
APIs (und der Systemkonzepte, die unterscheiden sich zwischen VMS
und Linux/Windows durchaus (ok, etwas weniger zu Windows aus historischen
Gründen)) so gut kennen, dass die sowas in "funktioniert gut" bauen kann.
Viel Spass.

Bedingt natürlich, dass
- man den _kompletten_ Quellcode für alle zu portierenden Softwaresysteme
hat (da hakt es gerne schon mal, Stichwort eingekaufte Bibliotheken)
- der vorhandene Quellcode auch wirklich mit den aktuell laufenden
Binaries korrelliert

Und selbst dann wird es noch genug Knackpunkte geben, die man zum Teil
halt leider auf die harte Tour finden wird.

Und eine Tretmine der ganz besonderen Art sind, falls vorhanden,
spezielle Hardwarekomponenten wie zum Beispiel I/O-Karten zur
Kommunikation mit externen Systemen (Messtechnik, Maschinensteuerung
und so weiter). Das kann man solange weiterschleppen wie man Ersatz-
teile für ersetzbare Systemkomponenten (den VAX/Alpha/Itanium Host)
bekommt und die nichtersetzbaren Komponenten nicht aussteigen, aber
irgendwann hilft halt nur noch "niederbrennen und neu aufbauen".

>>> Oder kann es sein das den Drei-Buchstaben Jungs die Alte HW mit dem
>>> Original langsam unterm Hintern verrottet?
>>
>> _Das_. Es gibt mittlerweile das Problem, das manche Organisationen sich
>> Ersatzteile und Reservehardware auf EBay erjagen müssen weil diese
>> seit 20+ Jahren nicht mehr hergestellt werden und auch die Lager der
>> "üblichen Verdächtigen" (schwer vergoldete Preise wegen 'Enterprise
>> Support', 'business continuity' usw.) zunehmend weniger hergeben.
> Hmm. Du meinst also das alle die noch so alte Geräte im Keller, Lager,
> Museum hätten damit rechnen müßten das ihnen eine ungenannte
> Organisation "Ein Angebot macht das sie nicht ablehnen könnten"?
>
> Kann schon Mist sein wenn man "den Schuß nicht gehört hat" oder? ;-)

Jo, es geht halt solange gut, bis es nicht mehr gut geht. *schulterzuck*

> Es gibt doch auch vermehrt Bestrebungen sich vordergründig von
> China-Exporten unabhängiger zu machen durch Rückverlagerung der
> Produktion im eigenen Lande (Speziell USA). Natürlich zu höheren Preisen
> aber bedenkt man das die Exporte wohl vor allem darum billiger sind weil
> A: Billige Arbeitskräfte und B: Günstiger Massentransport per Container
> dafür sorgen.

Du vergisst: C) wesentlich, ahem, "geschäftsfreundlichere" Regeln was
Umwelt- und Arbeitsschutz angeht und D) Subventionen durch den Staat um
gezielt die Konkurrenz finanziell trockenzulegen (siehe seltene Erden).

> Ändert nix an A & B könnte in großem Volumen aber
> Seiteneffekte haben wenn es viele (Natürlich Staatlich alimentiert)
> Durchführten.
>
> Endpunkt könnte der Niedergang der Exporte sein, Massenarbeitslosigkeit
> in China, und zu was der führen mag weiß keiner...

China ist ein Land, dass einen sehr reichen Speckgürtel an den Küsten hat,
gefüttert von Exporten, und ein riesengrossen sehr armes Hinterland. Chinas
Wirtschaft ist auf geradezu brutale Weise von Exporten (und Importen. sowohl
für Eigenbedarf als auch Exportproduktion) abhängig. Es gibt den Spruch
"Wenn Europa niest, kriegt China eine Lungenentzündung" - und der hat
seinen Grund. Die Versuche, den internen Markt zu stimulieren sind so
weit nicht sehr erfolgreich und haben u.a. zu einer _beeindruckenden_
und mittlerweile implodierenden Baublase geführt (Stichwort:
"china ghost cities").

> O-FeFe-J: "Hat bestimmt die CIA raus gefunden. Die finden alles raus..." :-)

Sind halt Blitzmerker ;-)

[Alexander Schreiber]

Hanno Foest <hurga...@tigress.com> wrote:
> Am 15.04.23 um 13:34 schrieb Alexander Schreiber:
>
>> Wie mir ein Kollege aus dem Telco-Bereich vor Jahren mal erzählte:
>> So in den 1990er lief der ganze SMS Verkehr bei IIRC E Plus wohl über
>> einen einzelnen HP-UX Server (oder gar workstation). Bis dann jemand
>> merkte das a) SMS werden nicht abgerechnet (weil damals wenig Nutzung)
>> b) man kann IP über SMS machen. Die resultierende SMS-Flut hat die
>> einzelne Maschine wohl recht schnell geplättet und _sehr_ kurze Zeit
>> später kosteten SMS dann Geld.
>
> Die Geschichte kenne ich etwas anders:

Mal wieder ein Fall von "chinese whispers", würde ich sagen ;-)

[Alexander Schreiber]

Diedrich Ehlerding <diedrich....@t-online.de> wrote:
> Kay Martinen meinte:
>
>>> Eher Firmen die seit VAX/Alpha Zeiten Wichtige Dinge (TM) auf VMS
>>> laufen haben und wo der letzte Mitarbeiter, der das System
>>> detailliert genug verstand um eine Portierung auf eine aktuelle
>>> Plattform zu ermöglichen schon seit Jahren in Rente ist ;-)
>>
>> Also wie üblich jene die
>>
>> - den Trend verschlafen haben.
>> - den Schuß nicht hörten.
>> - Geld sparen wollten um des Geld Verdienens wegen.
>
> Insbesondere diejenigen Firmen, deren IT-Verantwortliche eh nur einen 5-
> Jahres-Vertrag hatten, der jedes Jahr einen dicken Bonus beinhaltete -
> aber nur dann, wenn die Kostenstelle "IT" nicht etwa dicker wurde!
>
> Diese IT-Verantwortliche haben abkassiert, wussten vermutlich sehr gut,
> dass da eine Zeitbombe tickte - aber eben erst nach Ablauf ihres
> Vertrags platzen würde. Und deshalb haben sie dann rechtzeitig den
> Absprung auf ein anderes Unternehmen geschafft. Hätten sie nämlich
> rechtzeitig damit begonnen, ihre Systeme auf aktuelle Hardware zu
> portieren, hätte das viel Zeit und Geld gekostet, und der Bonus wäre
> flöten gewesen - "nach mir die Sinbtflut, soll sich doch mein nachfolger
> damit unbeliebt machen" ...

Man bekommt die Ergebnisse, für die man die Anreize liefert. Das sind
nicht notwendigerweise die Ergebnisse, die man gebraucht hätte.
Ist ja doof. ;-)

>> Insgesamt also welche bei denen sich das Mitleid in Grenzen hielte
>
> +1

Yup.

[Kay Martinen]

Am 15.04.23 um 20:12 schrieb Gerrit Heitsch:

> On 4/15/23 20:03, Stefan Möding wrote:
>> Gerrit Heitsch <ger...@laosinh.s.bawue.de> writes:
>>
>>> Und der hat ein paar sehr merkwürdige Dinger implementiert. Wie z.B. das man
>>> unter Windows eine in Benutzung befindliche Datei nicht löschen oder
>>> überschreiben kann. Was im täglichen Betrieb Ärger macht und Systemupdates
>>> unnötig kompliziert.

Weil das OS die binärdateien aus denen es selbst besteht offen hält
nachdem diese ins RAM kopiert wurden (zwecks ausführung)?

Mir ist als hätte ich bei W2k bei der Systemdateireparatur etwas
ähnliches gelesen.

>> ja, weil man beim Filesystem unbedingt rückwärtskompatibel bleiben
>> musste... VMS hat da ja eine schöne Versionierung der Files, womit
>> problemlos eine Kopie angelegt werden konnte und die alte Version
>> weiterhin existiert.

Und wie machte man das merging oder synchronisierung zwischen altem und
neuem inhalt?

>> Unter Unix kann man eine (geöffnete) Datei löschen und der Plattenplatz
>> wird nicht freigegeben. Das versteht auch nicht jeder.

DEV Papierkorb?

> Für mich eigentlich klar... Wer sie offen hat, der kann sie noch
> lesen/schreiben. Für alle anderen ist sie weg.

Und wenn der sie offen haltende sie dann beschrieben hat und
anschließend schließt, der hat dann mit zitronen gehandelt weil die neue
information dann gleich im bitmülleimer landet? Oder wird die alte datei
nach dem beschreiben und schließen dann wieder (magisch) auftauchen?

> Oder überschreiben. Wer die alte Datei offen hat bekommt den alten
> Inhalt. Sie verschwindet erst dann, wenn der letzte Benutzer sie
> freigegeben hat. Wer sie nicht offen hatte bekommt den neuen Inhalt.

User A öffnet datei1 und liest inhaltA
User B löscht datei1
User C öffnet datei1 und schreibt InhaltB
User A schreibt InhaltC in datei1 und schließt sie.
Welchen Inhalt sieht jetzt User C?
Und was sieht User B wenn er kontrolliert ob datei1 wirklich gelöscht wurde?

Ist so was nicht essentielles Datei-/Bereichs-locking und sollte solche
fälle verhindern? In JEDEM OS das mehr als Single-User/Single-Task kann.

Als ich meine Mailbox auf LAN umrüstete ist mir das anfangs ein paar mal
auf die füße gefallen da ich 'share' nicht geladen hatte. So konnte ich
eine Batchdatei auf dem Server im Editor offen haben, sie von einem DOS
client aus ebenfalls modifizieren, aber je nach dem welchen ich zuerst
mit speichern beendete unterschied sich der inhalt - wenn er überhaupt
noch lesbar war. Da Änderungen auch mal im laufenden Betrieb gemacht
wurden hat das gleich mehr als nur einen mailertask abgeschossen weil
sie alle über einen batch (nur mit LINE=x unterschieden) starteten.
Ja, man hätte für jeden ein kill- oder restart-semaphore hin werfen
können wenn man fertig ist aber da mußte man auch dran denken.

[Gerrit Heitsch]

Nein, die ist und bleibt weg.

>> Oder überschreiben. Wer die alte Datei offen hat bekommt den alten
>> Inhalt. Sie verschwindet erst dann, wenn der letzte Benutzer sie
>> freigegeben hat. Wer sie nicht offen hatte bekommt den neuen Inhalt.
>
> User A öffnet datei1 und liest inhaltA
> User B löscht datei1
> User C öffnet datei1 und schreibt InhaltB
> User A schreibt InhaltC in datei1 und schließt sie.
> Welchen Inhalt sieht jetzt User C?

InhaltB. Vorausgesetzt die Dateien sind jeweils offen gehalten worden.
InhaltC ist weg.

> Und was sieht User B wenn er kontrolliert ob datei1 wirklich gelöscht
> wurde?

Die neue Datei die von User C angelegt wurde.

Man darf nie mehrere User auf derselben Datei herumfurwerken lassen. Das
gibt _immer_ Ärger, egal wie man es dreht. Entweder hast du Locking und
dann vergisst User A die Datei zu schliessen während er was anderes
macht womit User B und C nicht arbeiten können bis man User A
kontaktiert hat ('Oh der ist heute nicht mehr im Haus...' Macht richtig
Spaß auf Sharepoint). Oder du hast kein Locking und dann können sich die
User gegenseitig die Datei zerschiessen.

> Ist so was nicht essentielles Datei-/Bereichs-locking und sollte solche
> fälle verhindern? In JEDEM OS das mehr als Single-User/Single-Task kann.

In Mutliuser-OS gibt es dafür Dateizugriffsrechte. Damit wird wirksam
verhindert, daß man anderen Usern die Dateien zerstört. Lesen kann man
meist, aber nicht schreiben.

Gerrit

[Alexander Schreiber]

Dennis Grevenstein <dennis.gr...@gmail.com> wrote:
> Michael Kraemer @ home <M.Kr...@gsi.de> wrote:
>>
>> Verwunderlich auch, dass, jedenfalls wenn man den Diskussionen auf c.o.v folgt,
>> so ziemlich alles, was einst VMS originaer von der Konkurrenz unterschied,
>> rausfliegt bzw rausfliegen sollte und durch irgendwas aus der Linux/UNIX Welt
>> ersetzt wird.
>
> c.o.v. ist halt auch ein seltsamer Ort im Internet.
>
>>> Oder kann es sein das den Drei-Buchstaben Jungs die Alte HW mit dem
>>> Original langsam unterm Hintern verrottet?
>>
>> Der Ruf nach der US-Kavallerie als Retter ist in letzter Zeit ziemlich leise
>> geworden.
>

> Ich glaube das bestimmt, dass da draussen Leute VMS im Einsatz haben,
> um SMSe zu sortieren oder ihre Pipeline zu steuern, aber wieviele
> Anwendungen, Lizenzen und Supportverträge sind das denn am Ende des
> Tages? Vor dem Hintergrund halte ich es für einigermaßen plausibel,
> dass es da irgendwen gibt, der VMS im Einsatz hat und vielleicht ohne
> VMS in seinem Bunker nicht mehr das Licht ein- und ausschalten könnte
> und daher motiviert ist, die show für alle zu bezahlen. Also jetzt
> schon, im Hintergrund, ohne dass es alle mitbekommen.

Bei irgendwelchen verbunkerten ICBMs in den USA sind wohl noch 5.25"
Floppies für bestimmte Zwecke im Einsatz. Die Systeme wurden halt vor
ewiger Zeit gebaut und installiert und ausser "uns gammelt die Hardware
so langsam weg" gibt es da auch nicht wirklich Anreiz, was Neues zu
entwickeln.

[Alexander Schreiber]

Dafür gibt es 'lsof|grep -i deleted' und /proc/${pid}/fd/ unter Linux.

Und "finde den mysteriösen Platzfüller" mit "gelöschte aber noch offene
Datei in die fröhlich weiter geschrieben wird" als Grund habe ich schon
als Interviewfrage für Sysadmins gesehen.

[Kay Martinen]

Am 16.04.23 um 16:29 schrieb Gerrit Heitsch:

> On 4/16/23 16:00, Kay Martinen wrote:
>> Am 15.04.23 um 20:12 schrieb Gerrit Heitsch:
>>> On 4/15/23 20:03, Stefan Möding wrote:
>>>> Gerrit Heitsch <ger...@laosinh.s.bawue.de> writes:
>>>>
>>>>> Und der hat ein paar sehr merkwürdige Dinger implementiert. Wie z.B.
>>>>> das man
>>>>> unter Windows eine in Benutzung befindliche Datei nicht löschen oder
>>>>> überschreiben kann.

>>>> ja, weil man beim Filesystem unbedingt rückwärtskompatibel bleiben
>>>> musste...  VMS hat da ja eine schöne Versionierung der Files, womit
>>>> problemlos eine Kopie angelegt werden konnte und die alte Version
>>>> weiterhin existiert.
>>
>> Und wie machte man das merging oder synchronisierung zwischen altem und
>> neuem inhalt?

Überhaupt nicht? Oder versionierung bei vms, bei allem anderen
|unix|linux|eNTe| nix?

>> Und wenn der sie offen haltende sie dann beschrieben hat und
>> anschließend schließt, der hat dann mit zitronen gehandelt weil die neue
>> information dann gleich im bitmülleimer landet? Oder wird die alte datei
>> nach dem beschreiben und schließen dann wieder (magisch) auftauchen?
>
> Nein, die ist und bleibt weg.

Das ist eingebaute Datenvernichtung. Da kann man auch gleich
/dev/schredder zum schreiben öffnen finde ich. :-/

Wenn VMS da auf Versionierung setzt wird mir langsam klar warum das
jemand neu haben wollte... :-)

Wobei ja speziell die eine 3-Buchstaben Organisation als
Datenstaubsauger bekannt ist. Suck,Analyze&Compress okay, aber Delete
wohl kaum.

>>> Oder überschreiben. Wer die alte Datei offen hat bekommt den alten
>>> Inhalt. Sie verschwindet erst dann, wenn der letzte Benutzer sie
>>> freigegeben hat. Wer sie nicht offen hatte bekommt den neuen Inhalt.
>>
>> User A öffnet datei1 und liest inhaltA
>> User B löscht datei1
>> User C öffnet datei1 und schreibt InhaltB
>> User A schreibt InhaltC in datei1 und schließt sie.
>> Welchen Inhalt sieht jetzt User C?
>
> InhaltB. Vorausgesetzt die Dateien sind jeweils offen gehalten worden.
> InhaltC ist weg.

Ich kenne es so das RW Zugriff Vorrang hat vor RO wobei aber sicher
jeder Editor die datei gleich RW öffnet auch wenn er sie nur einliest.
Er "könnte" sie ja beschreiben und müßte sie sonst ggf. erneut öffnen
wenn er es wirklich tun wollte.

Tools wie tail oder less sollten dies Problem nicht haben/verursachen
weil sie nur auslesen. Wobei dies bei logfiles nach dem rotate auch ein
Problem sein kann. :)

>> Und was sieht User B wenn er kontrolliert ob datei1 wirklich gelöscht
>> wurde?
>
> Die neue Datei die von User C angelegt wurde.
>
> Man darf nie mehrere User auf derselben Datei herumfurwerken lassen. Das
> gibt _immer_ Ärger, egal wie man es dreht. Entweder hast du Locking und
> dann vergisst User A die Datei zu schliessen während er was anderes
> macht womit User B und C nicht arbeiten können bis man User A
> kontaktiert hat ('Oh der ist heute nicht mehr im Haus...' Macht richtig
> Spaß auf Sharepoint). Oder du hast kein Locking und dann können sich die
> User gegenseitig die Datei zerschiessen.

Wenn 'löschen einer Datei' auch ein Schreibvorgang ist dann sollte nach
meinem Verständnis User B schon eine Ablehnende Antwort; mit verweis auf
User A; bekommen und User C ebenfalls nicht erlaubt sein diese RW zu
öffnen. Andernfalls müßte bei den Versuchen von User B und C der User A;
dessen Programm; benachrichtigt werden das ihm der lesende Zugriff
entzogen wurde. User idle, programm läuft, datei wech = Zombie oder
kill&wech damit?

>> Ist so was nicht essentielles Datei-/Bereichs-locking und sollte solche
>> fälle verhindern? In JEDEM OS das mehr als Single-User/Single-Task kann.
>
> In Mutliuser-OS gibt es dafür Dateizugriffsrechte. Damit wird wirksam
> verhindert, daß man anderen Usern die Dateien zerstört. Lesen kann man
> meist, aber nicht schreiben.

du meinst z.b. bei Linux -rw-rw-rw? Wobei der Eigner, Mitglieder der
gleichen Gruppe (users z.b.) und 'alle anderen' sie ja ebenfalls RW
öffnen könnten. Aber warum müsste dann ein 'chmod 0600' nötig sein um es
auf -rw------ zu begrenzen? Locking sollte teil des OS sein und einen
Zweiten aufruf der gleichen datei mit Ziel RW verhindern oder den 2.
eben nur RO zulassen. Dann kann einer schreiben und alle anderen nur
zusehen (RO). Problem gelöst oder?

Zugriffsrechte sind schön und gut, haben m.E. aber mit locking nix zu
tun. Im grunde käme das locking erst NACH dem Zugriffsrecht zum Tragen.

[Stefan Möding]

Kay Martinen <use...@martinen.de> writes:

> Und wie machte man das merging oder synchronisierung zwischen altem und neuem
> inhalt?

Wenn die Anwendung die Datei neu schreibt, dann ist das eine neue
Version. Der Editor liest also beispielsweise das File "FOO.TXT;1" (erste
Version einer Textdatei) und beim Abspeichern entsteht dann zusätzlich
"FOO:TXT;2" als zweite Version. Unter dem alten Namen kann man immer noch
auf den alten Inhalt zugreifen. Gibt man keine Versionsnummer an
("FOO.TXT") ist die letzte Version gemeint.

Wenn die Anwendung nur innerhalb der Datei ändert, dann entsteht auch
keine neue Version, d.h. eine Datenbank könnte den ganzen Tag in
"FOO.DB;1" ändern, wie man das unter Unix/Linux auch tun würde.

> User A öffnet datei1 und liest inhaltA
> User B löscht datei1
> User C öffnet datei1 und schreibt InhaltB
> User A schreibt InhaltC in datei1 und schließt sie.
> Welchen Inhalt sieht jetzt User C?
> Und was sieht User B wenn er kontrolliert ob datei1 wirklich gelöscht wurde?

> Ist so was nicht essentielles Datei-/Bereichs-locking und sollte solche fälle
> verhindern? In JEDEM OS das mehr als Single-User/Single-Task kann.

Darum ging's mir. Einmal gibt es die Meinung, dass Locking doof ist, weil
es das Kopieren im Rahmen eines Updates verhindert und andererseits kommt
dann die Frage auf, warum solche Sachen wie hier nicht durch das OS
verhindert werden.

Unix/Linux verhindert übrigens durchaus das Verändern eines laufenden
Executables:

# cp /bin/bash ~
# exec ~/bash
# echo >~/bash
bash: /root/bash: Text file busy

Das Installieren eines neuen Executables beim Update geht nur dann, wenn
vorher die existierende Version gelöscht wird. Bei VMS hätte man dann eben
auch zwei Files, die sich in der Versionsnummer unterscheiden. Bei
Unix/Linux hat man nur ein File und eine nicht mehr sichtbare Datei, die
noch Plattenplatz belegt.

--
Stefan

[Kay Martinen]

Am 16.04.23 um 17:52 schrieb Alexander Schreiber:

> Dennis Grevenstein <dennis.gr...@gmail.com> wrote:
>> Michael Kraemer @ home <M.Kr...@gsi.de> wrote:

>>> ich schrieb:

>>>> Oder kann es sein das den Drei-Buchstaben Jungs die Alte HW mit dem
>>>> Original langsam unterm Hintern verrottet?
>>>
>>> Der Ruf nach der US-Kavallerie als Retter ist in letzter Zeit ziemlich leise
>>> geworden.

Vermutlich weil die sich jetzt eher "Army" nennen lassen. Drei
Buchstaben-Kürzel kann ich in beidem nicht erkennen.

PFERD->JEEP->MUTT->Humwee->Elektrische Reiter??? Wow, was'n Fortschritt.

>> Tages? Vor dem Hintergrund halte ich es für einigermaßen plausibel,
>> dass es da irgendwen gibt, der VMS im Einsatz hat und vielleicht ohne
>> VMS in seinem Bunker nicht mehr das Licht ein- und ausschalten könnte
>> und daher motiviert ist, die show für alle zu bezahlen. Also jetzt
>> schon, im Hintergrund, ohne dass es alle mitbekommen.
>
> Bei irgendwelchen verbunkerten ICBMs in den USA sind wohl noch 5.25"
> Floppies für bestimmte Zwecke im Einsatz. Die Systeme wurden halt vor
> ewiger Zeit gebaut und installiert und ausser "uns gammelt die Hardware
> so langsam weg" gibt es da auch nicht wirklich Anreiz, was Neues zu
> entwickeln.

Zumindest Früher (TM) war eine übliche sperrklausel in PD oder Shareware
zu finden die den Einsatz für Militärische Zwecke ausschloß. Ob sich da
jemand bei $GEHEIM für interessierte weil es ja $GEHEIM war und ist...

... aber wenn vielleicht die eine Hälfte der US IT-Bevölkerung Glühende
Patrioten sind (und nicht programmieren können) und die andere dir eher
die Tür vor der Nase zu schlägt wenn es heißt "Programmier uns mal was
neues für die ICBM's" dann hast du auch ein Personal-Problem was die
Migration auf neueres angeht.

Immerhin soll der Alte Kram ja wohl Y2K Fest gewesen sein. Man hat ja
seinerzeit herbei schwadroniert das die Raketen/Bomben sich dann selbst
starten/sprengen könnten. Doomsday ist morgen, Ganz bestimmt. :)

BTW. Ist das mal jemandem aufgefallen? In der Berichterstattung zum
Atomausstieg am 15.4. ließt es sich immer so als ob 5 Minuten nach dem
raus ziehen des Roten Knopfes alles schon kalt wäre (wie die
Sektflaschen bei den Grünen?) und sofort ein Abrißtrupp los legen könne.
Ja, von wegen. Erst mal die Nachzerfallswärme (etliche MegaWatt) raus
kühlen und in ein paar Wochen/Monaten dann vielleicht der nächste
Schritt... Castoren->Zwischenlager, u.s.w.

Heißt: Wenn jetzt einer hin guckt wird wohl noch weißer Rauch aus den
Kühltürmen kommen. Immerhin besser als Schwarzer Rauch aus dem Reaktor
selbst. Und ich bin eigentlich *nicht* /gegen/ Kernkraft-Nutzung. :-)

[Gerrit Heitsch]

Ist eben so. Der Ansatz bietet Freiheit und zur Freiheit gehört auch
immer, daß man sich damit selbt schaden kann wenn man nicht aufpasst.

>>> Und was sieht User B wenn er kontrolliert ob datei1 wirklich gelöscht
>>> wurde?
>>
>> Die neue Datei die von User C angelegt wurde.
>>
>> Man darf nie mehrere User auf derselben Datei herumfurwerken lassen. Das
>> gibt _immer_ Ärger, egal wie man es dreht. Entweder hast du Locking und
>> dann vergisst User A die Datei zu schliessen während er was anderes
>> macht womit User B und C nicht arbeiten können bis man User A
>> kontaktiert hat ('Oh der ist heute nicht mehr im Haus...'  Macht richtig
>> Spaß auf Sharepoint). Oder du hast kein Locking und dann können sich die
>> User gegenseitig die Datei zerschiessen.
>
> Wenn 'löschen einer Datei' auch ein Schreibvorgang ist dann sollte nach
> meinem Verständnis User B schon eine Ablehnende Antwort; mit verweis auf
> User A; bekommen und User C ebenfalls nicht erlaubt sein diese RW zu
> öffnen.

Ja, und schon hast du Ärger weil dir ein User eine Datei komplett
blocken kann. Das ist ja das Problem mit dem Locking.

Gerrit

[Dennis Grevenstein]

Kay Martinen <use...@martinen.de> wrote:
>
> BTW. Ist das mal jemandem aufgefallen? In der Berichterstattung zum
> Atomausstieg am 15.4. ließt es sich immer so als ob 5 Minuten nach dem
> raus ziehen des Roten Knopfes alles schon kalt wäre (wie die
> Sektflaschen bei den Grünen?) und sofort ein Abrißtrupp los legen könne.
> Ja, von wegen. Erst mal die Nachzerfallswärme (etliche MegaWatt) raus
> kühlen und in ein paar Wochen/Monaten dann vielleicht der nächste
> Schritt... Castoren->Zwischenlager, u.s.w.
>
> Heißt: Wenn jetzt einer hin guckt wird wohl noch weißer Rauch aus den
> Kühltürmen kommen. Immerhin besser als Schwarzer Rauch aus dem Reaktor
> selbst. Und ich bin eigentlich *nicht* /gegen/ Kernkraft-Nutzung. :-)

Die Politik kann eben die Gesetz der Physik noch nicht ändern.

Aufgrund der allgemeinen Weltlage muss die Rettung des Planeten
sowieso erstmal warten. Da haben sich die Prioritäten der Politik
verändert.

gruss,
Dennis

--
"I've seen things you people wouldn't believe. Attack ships on fire off the

shoulder of Orion. I watched C-beams glitter in the dark near the Tannhäuser

[Dennis Grevenstein]

p...@pocnet.net wrote:
>
> Gibt es denn kommerzielle Emulatoren? Meien Erfahrungen mit Netzwerk vs. SimH
> vor einigen Jahren waren nicht so prickelnd.

ja, die gibt es.

Für Alpha:
https://www.tristate.co.uk/alpha-system-emulator/

schon lange in "production quality" für VAX:
https://www.stromasys.com/solution/charon-vax

>> VMS ist halt kein mainframe.
>
> Was genau meinst Du damit?

VMS war immer etwas konservativer gebaut als Unix. Es hat sich
weniger verändert. Man hat mehr Wert auf binärkompatibiltät
gelegt. Alte Systeme wurden sehr lange unterstützt. IBM hat aber
wohl den Standard gesetzt für Langlebigkeit.

[Kay Martinen]

Am 16.04.23 um 19:13 schrieb Gerrit Heitsch:

> On 4/16/23 18:36, Kay Martinen wrote:
>> Am 16.04.23 um 16:29 schrieb Gerrit Heitsch:
>>> On 4/16/23 16:00, Kay Martinen wrote:

>>>> Und wenn der sie offen haltende sie dann beschrieben hat und
>>>> anschließend schließt, der hat dann mit zitronen gehandelt weil die neue
>>>> information dann gleich im bitmülleimer landet?

>>> Nein, die ist und bleibt weg.
>>
>> Das ist eingebaute Datenvernichtung. Da kann man auch gleich
>> /dev/schredder zum schreiben öffnen finde ich. :-/
>
> Ist eben so. Der Ansatz bietet Freiheit und zur Freiheit gehört auch
> immer, daß man sich damit selbt schaden kann wenn man nicht aufpasst.

Schade das 'tron' dann nicht einfach 'rm mcp' oder im 2. Teil 'rm clu'
machen konnte oder? Scheiß Dramaturgie aber der Film wäre in 5 min.
erledigt. Wenn nicht die Zugriffs-sperren gewesen wären. :)

Freiheit Radikal gedacht bedeutet auch sich selbst in's Knie schießen zu
dürfen. Okay.

>>> Man darf nie mehrere User auf derselben Datei herumfurwerken lassen. Das
>>> gibt _immer_ Ärger, egal wie man es dreht. Entweder hast du Locking und
>>> dann vergisst User A die Datei zu schliessen während er was anderes
>>> macht womit User B und C nicht arbeiten können bis man User A
>>> kontaktiert hat ('Oh der ist heute nicht mehr im Haus...'  Macht richtig
>>> Spaß auf Sharepoint). Oder du hast kein Locking und dann können sich die
>>> User gegenseitig die Datei zerschiessen.
>>
>> Wenn 'löschen einer Datei' auch ein Schreibvorgang ist dann sollte nach
>> meinem Verständnis User B schon eine Ablehnende Antwort; mit verweis auf
>> User A; bekommen und User C ebenfalls nicht erlaubt sein diese RW zu
>> öffnen.
>
> Ja, und schon hast du Ärger weil dir ein User eine Datei komplett
> blocken kann. Das ist ja das Problem mit dem Locking.

Das ist ein Layer 8 Problem. Und sollte auch dort gelöst werden. Wenn
dazu ein "Ey, gib die Schei&§$&§ Datei endlich frei" gehört dann muß es
eben so sein.

Ich glaube aber das Sharepoint kein gutes Beispiel sein dürfte - Schon
weil es ein MS-Elaborat ist.

[Gerrit Heitsch]

On 4/16/23 21:08, Kay Martinen wrote:
> Am 16.04.23 um 19:13 schrieb Gerrit Heitsch:
>> On 4/16/23 18:36, Kay Martinen wrote:
>>> Am 16.04.23 um 16:29 schrieb Gerrit Heitsch:
>>>> On 4/16/23 16:00, Kay Martinen wrote:
>
>>>>> Und wenn der sie offen haltende sie dann beschrieben hat und
>>>>> anschließend schließt, der hat dann mit zitronen gehandelt weil die
>>>>> neue
>>>>> information dann gleich im bitmülleimer landet?
>
>>>> Nein, die ist und bleibt weg.
>>>
>>> Das ist eingebaute Datenvernichtung. Da kann man auch gleich
>>> /dev/schredder zum schreiben öffnen finde ich. :-/
>>
>> Ist eben so. Der Ansatz bietet Freiheit und zur Freiheit gehört auch
>> immer, daß man sich damit selbt schaden kann wenn man nicht aufpasst.
>
> Schade das 'tron' dann nicht einfach 'rm mcp' oder im 2. Teil 'rm clu'
> machen konnte oder? Scheiß Dramaturgie aber der Film wäre in 5 min.
> erledigt. Wenn nicht die Zugriffs-sperren gewesen wären. :)

Ist dasselbe mit anderen Filmen. Da gibt es einen der heisst 'Auf der
Flucht' und nicht 'Geschnappt nach 5 min'.

>> Ja, und schon hast du Ärger weil dir ein User eine Datei komplett
>> blocken kann. Das ist ja das Problem mit dem Locking.
>
> Das ist ein Layer 8 Problem. Und sollte auch dort gelöst werden. Wenn
> dazu ein "Ey, gib die Schei&§$&§ Datei endlich frei" gehört dann muß es
> eben so sein.

Und dann ist der fragliche User im Meeting oder gar nicht mehr im Haus.

> Ich glaube aber das Sharepoint kein gutes Beispiel sein dürfte - Schon
> weil es ein MS-Elaborat ist.

Sharepoint will mir auch nicht gefallen.

Gerrit

[Kay Martinen]

Am 16.04.23 um 19:21 schrieb Dennis Grevenstein:

> Kay Martinen <use...@martinen.de> wrote:
>>
>> BTW. Ist das mal jemandem aufgefallen? In der Berichterstattung zum
>> Atomausstieg am 15.4. ließt es sich immer so als ob 5 Minuten nach dem
>> raus ziehen des Roten Knopfes alles schon kalt wäre (wie die
>> Sektflaschen bei den Grünen?) und sofort ein Abrißtrupp los legen könne.
>> Ja, von wegen. Erst mal die Nachzerfallswärme (etliche MegaWatt) raus
>> kühlen und in ein paar Wochen/Monaten dann vielleicht der nächste
>> Schritt... Castoren->Zwischenlager, u.s.w.
>>
>> Heißt: Wenn jetzt einer hin guckt wird wohl noch weißer Rauch aus den
>> Kühltürmen kommen. Immerhin besser als Schwarzer Rauch aus dem Reaktor
>> selbst. Und ich bin eigentlich *nicht* /gegen/ Kernkraft-Nutzung. :-)
>
> Die Politik kann eben die Gesetz der Physik noch nicht ändern.

*Noch* nicht? :-)

Dabei soll(te) es eigentlich umgekehrt sein das die Physik die Politik
verändern muß. Aber wenn Politiker X auf Experte Y nicht hören will weil
Lobbyist Z zu laut "flüstert"... Tja dann. NIH. NmdSF

> Aufgrund der allgemeinen Weltlage muss die Rettung des Planeten
> sowieso erstmal warten. Da haben sich die Prioritäten der Politik
> verändert.

Ich sag's ja schon seit Jahrzehnten. Die Menschheit als Ganzes arbeitet
wirklich sehr Hart an ihre Eigenen Ausrottung. Da kann man nicht mehr
mit Physik und Beweisen daher kommen. Da hilft nur noch ein 4.
Weltkrieg. Hast du deine Pompfe und Pfeile & Bogen schon bereit liegen?

:-/

Jeder Mensch braucht: Luft, Wasser, Nahrung, Beschäftigung, Zeit.
Was macht die Politik: Sie verschwendet Zeit, Luft, Wasser, Nahrung und
sorgt eher für weniger Beschäftigung.

Eigentlich sollte man die ganze Bande (weltweit) wg. Bruch der
Menschenrechte (o.ä.) anklagen... Veto, ick hör dir Tapsen!

[Kay Martinen]

Am 16.04.23 um 21:24 schrieb Gerrit Heitsch:

> On 4/16/23 21:08, Kay Martinen wrote:
>> Am 16.04.23 um 19:13 schrieb Gerrit Heitsch:

>>> Ist eben so. Der Ansatz bietet Freiheit und zur Freiheit gehört auch
>>> immer, daß man sich damit selbt schaden kann wenn man nicht aufpasst.
>>
>> Schade das 'tron' dann nicht einfach 'rm mcp' oder im 2. Teil 'rm clu'
>> machen konnte oder? Scheiß Dramaturgie aber der Film wäre in 5 min.
>> erledigt. Wenn nicht die Zugriffs-sperren gewesen wären. :)
>
> Ist dasselbe mit anderen Filmen. Da gibt es einen der heisst 'Auf der
> Flucht' und nicht 'Geschnappt nach 5 min'.

Dagegen haben sie bei "Demolition Man" die Musik der TV-Ads als
Kurzmusik eingedampft. Der Film ist aber doch länger. ;)

Das "Drama" muß ja erst mal seinen Lauf gehen.

>>> Ja, und schon hast du Ärger weil dir ein User eine Datei komplett
>>> blocken kann. Das ist ja das Problem mit dem Locking.
>>
>> Das ist ein Layer 8 Problem. Und sollte auch dort gelöst werden. Wenn
>> dazu ein "Ey, gib die Schei&§$&§ Datei endlich frei" gehört dann muß es
>> eben so sein.
>
> Und dann ist der fragliche User im Meeting oder gar nicht mehr im Haus.

Bitte an admin ein 'kill' ab zu setzen. Oder sind wir dann gleich wieder
bei einem gnu movemail Problem? [Kuckucksei] :-)

Drama! Drama!

Ich fände es generell besser wenn mir das OS sagt da darf ich nicht ran,
die hat jemand (x) schon auf. Denn dann kann ich nach x suchen statt
mutwillig/zufällig daten zu zerstören.

Wo es früher nur 'finger' und 'talk' gab, oder 'mail' da gibt es heute
doch 'messenger' jeder Art und im Business gilt doch eh 24/7
Erreichbarkeit oder? Man könnte ja was (Börsenkurs, Feindliche
Übernahme, Hackerangriff, whatever) verpassen...

Wenn Glück und Geschick von $Firma davon abhängen geht m.E. "daten
bewahren" vor "Daten kaputt" und ein "logge dich aus wenn du weg gehst"
sollte man aus div. Gründen eh jedem Mitarbeiter nahe gelegt haben.

Und $Privat reicht vermutlich schon ein Brüllen durch's Haus oder das
Anstupsen des Partners neben sich. ;)

Ich bin ja sonst kein Freund davon Soziale Probleme auf Krampf Technisch
lösen zu wollen. Aber hierbei sehe ich eigentlich kein Wirkliches
Problem. Nur die üblichen o.g. Lösungswege.

[Gerrit Heitsch]

> Anstupsen des Partners neben sich. ;)
>
> Ich bin ja sonst kein Freund davon Soziale Probleme auf Krampf Technisch
> lösen zu wollen. Aber hierbei sehe ich eigentlich kein Wirkliches
> Problem. Nur die üblichen o.g. Lösungswege.

Ich schon, bei Updates. Während das OS läuft hast du jede Menge offene
Dateien. Bei den meisten Updates werden einige davon überschrieben
werden müssen, während das OS läuft und sie benutzt.

Mit Locking bekommst du dann die Probleme wie bei Windows.

Gerrit

[Kay Martinen]

Am 16.04.23 um 22:03 schrieb Gerrit Heitsch:

> Ich schon, bei Updates. Während das OS läuft hast du jede Menge offene
> Dateien. Bei den meisten Updates werden einige davon überschrieben
> werden müssen, während das OS läuft und sie benutzt.

Geht es (dir?) dabei um die Vermeidung eines Reboots um updates ab zu
schließen? Das ist ja bei Win und OS/2 übliches Verfahren, bei Linux nur
wenn es Kernel oder dem naheliegende Komponenten betrifft. Obwohl
Live-patching aktuell mehr diskutiert wurde, wie ich so las.

> Mit Locking bekommst du dann die Probleme wie bei Windows.

Bei Binärdateien die nur lesend geöffnet werden!

Ich dachte wir sprechen hier von Benutzerdateien eines unixoiden Systems
und nicht von systemfiles - weil du zu VMS Versionierung erwähntest. Ein
Benutzer wird doch wohl kaum systemdateien offen haben, Oder?

Ich nahm an das ein OS hier eine Unterscheidung vornehmen kann. Wenn
nicht anhand der Zugriffsrechte im Dateisystem so doch zumindest anhand
interner Strukturen wie kernel-mode, ring0 vs. ring 3 oder; als
schlechteste aller Möglichkeiten; anhand von dateityp oder datei-endung
(sofern verfügbar).

Kurzum habe ich angenommen das Locking für userprogresse und dateien
möglich und implizit verwendet wird und nur bei binärdateien,
ausführbarem davon ausnahmen gemacht würden.

Hmm. Atomare Operation, Race Conditions wenn nicht? Gehts darum und
keine Andere Lösung?

[Hermann Riemann]

Am 16.04.23 um 21:20 schrieb Kay Martinen:

> Am 16.04.23 um 19:21 schrieb Dennis Grevenstein:
>> Kay Martinen <use...@martinen.de> wrote:
>>>
>>> BTW. Ist das mal jemandem aufgefallen? In der Berichterstattung zum
>>> Atomausstieg am 15.4. ließt es sich immer so als ob 5 Minuten nach dem
>>> raus ziehen des Roten Knopfes alles schon kalt wäre (wie die
>>> Sektflaschen bei den Grünen?) und sofort ein Abrißtrupp los legen könne.
>>> Ja, von wegen. Erst mal die Nachzerfallswärme (etliche MegaWatt) raus
>>> kühlen und in ein paar Wochen/Monaten dann vielleicht der nächste
>>> Schritt... Castoren->Zwischenlager, u.s.w.
>>>
>>> Heißt: Wenn jetzt einer hin guckt wird wohl noch weißer Rauch aus den
>>> Kühltürmen kommen. Immerhin besser als Schwarzer Rauch aus dem Reaktor
>>> selbst. Und ich bin eigentlich *nicht* /gegen/ Kernkraft-Nutzung. :-)
>>
>> Die Politik kann eben die Gesetz der Physik noch nicht ändern.
>
> *Noch* nicht? :-)
>
> Dabei soll(te) es eigentlich umgekehrt sein das die Physik die Politik

> verändern muss.

Muss?
Die Physik richtet sich nicht nach Politik.
Die Politik richtet sich nach der hardware im Ionen computer Gehirn,
dessen BIOS genetisch durch Evolution
( meist <= Tierentwicklung wie Hackordnung)
bestimmt ist, mit der gelegentlichen Auswertung von Daten
aus der Realität:
(
Input Sinnesorgane, dann Signalumformung, Zwischensprachen
)

> Aber wenn Politiker X auf Experte Y nicht hören will weil
> Lobbyist Z zu laut "flüstert"... Tja dann. NIH. NmdSF

Wer versteht schon Mathematik?
Im virtuellen Raum des Poker Spiels sind andere Prioritäten relevanter.

>> Aufgrund der allgemeinen Weltlage muss die Rettung des Planeten
>> sowieso erstmal warten. Da haben sich die Prioritäten der Politik
>> verändert.

> Ich sag's ja schon seit Jahrzehnten.

Und wer hat das mitbekommen?

> Die Menschheit als Ganzes arbeitet
> wirklich sehr Hart an ihre Eigenen Ausrottung.

Als Ganzes eher nicht.
Eher als einzelne Strömungen
wie gewalttätige und/oder ökonomische Machtkämpfe,
Konsumismus ( Spaß wichtiger als Überleben )

> Da kann man nicht mehr mit Physik und Beweisen daher kommen.

Vielleicht kann man computer auf Physik und Beweise
statt vorherrschende Meinungen wie bei Religion oder Gewinnstreben
umstellen.
Wie bei windoof und apple werden die ja wie Götter verehrt
und bestimmen (derzeit noch über GUIs) das eigene Handeln.

> Da hilft nur noch ein 4. Weltkrieg.

Es gibt ja schon Gegenmaßnahmen.
Z.B. Zucker. Menschen werden dicker und bekommen weniger Kinder.

Die Frage ist eher der schnelle Ersatz von Menschen durch Roboter..
und künstlich erzeugte biologische Wesen.
Die Menschen können ja als Demoversionen in Zoos
zur Darstellung fehlentwickelter Evolution weiter existieren.

> Hast du deine Pompfe und Pfeile & Bogen schon bereit liegen?

Wenn Munition wie Holz zur Neige geht..

> Jeder Mensch braucht: Luft, Wasser, Nahrung, Beschäftigung, Zeit.
> Was macht die Politik: Sie verschwendet Zeit, Luft, Wasser, Nahrung und
> sorgt eher für weniger Beschäftigung.

Beschäftigung? Das besorgen computer.
Momentan scheint es mir, dass Menschen ohne handy + Nachfolge (VR?)
am aussterben sind.

> Eigentlich sollte man die ganze Bande (weltweit) wg. Bruch der
> Menschenrechte (o.ä.) anklagen... Veto, ick hör dir Tapsen!

Ich habe schon angefangen ein Nürnberg 2045 zu überlegen.
Wo Verletzungen und töten ( Massenhinrichtung von 6 Mrd Personen)
verhandelt werden könnte.
Bleibt vermutlich virtuell, da die Neonazis gewinnen,
wobei sie die Selbstzerstörung weiterhin ignorieren.

Hermann
der gerne KI + Biophysik machen würde,
aber im Moment nach Ersatz für nicht funktionierenden
SDF_ttf sucht.
( Kandidat GTK oder QT mit Austausch über shared memory.
Ersatz für einfaches cgi in Python3 ist auch noch offen;
könnte über Analyse von stdout gehen. )

--
http://www.hermann-riemann.de

[Gerrit Heitsch]

On 4/16/23 22:57, Kay Martinen wrote:
> Am 16.04.23 um 22:03 schrieb Gerrit Heitsch:
>
>> Ich schon, bei Updates. Während das OS läuft hast du jede Menge offene
>> Dateien. Bei den meisten Updates werden einige davon überschrieben
>> werden müssen, während das OS läuft und sie benutzt.
>
> Geht es (dir?) dabei um die Vermeidung eines Reboots um updates ab zu
> schließen? Das ist ja bei Win und OS/2 übliches Verfahren, bei Linux nur
> wenn es Kernel oder dem naheliegende Komponenten betrifft. Obwohl
> Live-patching aktuell mehr diskutiert wurde, wie ich so las.

Ja, Systemupdates sollten soweit wie möglich ohne Reboot machbar sein.
Kernel wäre eine der Ausnahmen und auch daran wird gearbeitet wie du
schreibst.

>> Mit Locking bekommst du dann die Probleme wie bei Windows.
>
> Bei Binärdateien die nur lesend geöffnet werden!
>
> Ich dachte wir sprechen hier von Benutzerdateien eines unixoiden Systems
> und nicht von systemfiles - weil du zu VMS Versionierung erwähntest. Ein
> Benutzer wird doch wohl kaum systemdateien offen haben, Oder?

Aber sicher doch, oder was meinst was mit den ganzen shared libraries in
/lib und /usr/lib ist? Nimm ein beliebiges Anwendungsprogramm und schau
mit 'ldd' nach welche Libraries benutzt werden.

Gerrit