kann mir irgendjemand von Euch den Unterschied zwischen VMS und Unix
i.A. erklaeren? Sind doch beides 32-bit/Multiuser/Multitask-BS, gibt es
da einen gravierenden unterschied?
Na denn, Gruss Urs...
--
Dekliniere "Werwolf"!
Der Werwolf, des Weswolfs, dem Wemwolf, den Wenwolf!
Fuer Englischfans: how much wood could a woodchuck chuck,
if a woodchuck could chuck wood?
In article <34841D...@rz.tu-ilmenau.de>, Urs Traenkner
Alle auf ihn! Das gibt 'ne astreine VMS vs. Unix-Diskussion
Eberhard
Hier mein Beitrag:
VMS is' geil. *nix is' nix.
Aha. ich habe Dich aber nicht nach Deiner Meinung, sondern nach den
Unterschieden gefragt ;)
Im uebrigen laeuft dieser Thread in de.comp.os.vms UND de.comp.os.unix.
Haette das vielleicht erwaehnen sollen.
Koennt Euch gern die Koeppe einschlagen, das is mir Wurscht. Aber bitte
_nachdem_ ihr meine Frage beantwortet habt!
> kann mir irgendjemand von Euch den Unterschied zwischen VMS und Unix
> i.A. erklaeren? Sind doch beides 32-bit/Multiuser/Multitask-BS, gibt
> es
> da einen gravierenden unterschied?
Da gibt es schon einige Unterschiede.
Zunächst mal ist die Cluster-Technologie unter VMS wesentlich
ausgereifter als in allen Unix-Derivaten, vor allen Dingen deswegen,
weil sie dort bereits seit 1984 verfügbar ist und weil die
VMS-Cluster-Technologie und VMS eben optimal aufeinander abgestimmt sind
bzw. direkt füreinander entwickelt wurden und tief ineinander verzahnt
sind. Das macht VMS zu einem idealen Betriebssystem für hochverfügbare
Umgebungen - und dort wird es auch heute noch intensiv benutzt.
Ein VMS-System kann locker hunderte, wenn nicht tausende von Benutzern
vertragen, sei es interaktive Terminal-User (auch sowas gibt's noch)
oder PC-Clients am Pathworks-Netz. Das liegt unter anderem an dem
ausgereiften Scheduler und der Memory-Management-Strategie.
Das VMS-File-System ist recht ausgereift. Das Betriebssystem unterstützt
z.B. ohne weiteres ISAM-Files, enthält sogar ein kleines Experten-System
zum File-Design.
Und nicht zuletzt ist VMS auch, sagen wir mal,
System-Manager-freundlicher. Das fängt mir der Kommandosprache DCL an,
in der man viele Sachen machen kann, ohne ein Programm zu schreiben.
Gut, Unix hat die Shell(s), aber sowas wie lexical functions gibt es in
Unix nicht. Aber auch die System-Management-Utilities unter VMS können
sich sehen lassen.
--
Manfred Härtel
Sprecher der VMS-SIG bei DECUS München e.V.
http://www.decus.de
> Aha. ich habe Dich aber nicht nach Deiner Meinung, sondern nach den
> Unterschieden gefragt ;)
Die Frage wäre wohl eher, ob es außer der 32-bit-Architektur, die VMS
mit einer Reihe von Unixen teilt, und der Tatsache, daß ein VM-System
benutzt wird, tatsächlich noch mehr Gemeinsamkeiten zu finden
wären. ;-)
--
cheers, J"org
joerg_...@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
> Manfred Härtel
> Sprecher der VMS-SIG bei DECUS München e.V.
> http://www.decus.de
Na gut, kein Wunder... ich werde mich da lieber fast jeden Kommentars
enthalten, sonst geht das hier ins Uferlose...
Nur eins:
> Ein VMS-System kann locker hunderte, wenn nicht tausende von Benutzern
> vertragen, sei es interaktive Terminal-User (auch sowas gibt's noch)
> oder PC-Clients am Pathworks-Netz.
Will ich nicht bestreiten, allerdings mag ich hier in den Raum
stellen, daß das ein Unix-System genauso locker tut. Melde Dich bei
nächster Gelegenheit mal auf ftp.cdrom.com an und sieh nach, der
wievielte Benutzer Du dort gerade bist...
> kann mir irgendjemand von Euch den Unterschied zwischen VMS und Unix
> i.A. erklaeren?
Kann mir irgend jemand von Euch den Unterschied zwischen einer Katze und
einem Kuerbis erklaeren?
--
Christian "naddy" Weisgerber na...@mips.rhein-neckar.de
See another pointless homepage at <URL:http://home.pages.de/~naddy/>.
> Manfred...@t-online.de (Manfred Haertel) schrieb:
>
> > Manfred Härtel
> > Sprecher der VMS-SIG bei DECUS München e.V.
> > http://www.decus.de
>
> Na gut, kein Wunder... ich werde mich da lieber fast jeden Kommentars
> enthalten, sonst geht das hier ins Uferlose...
Warum? Ich habe nichts gegen einen sachlichen Austausch von Argumenten.
Es gibt schließlich auch Dinge, bei denen Unix VMS überlegen ist. Z.B.
kann man in Shell-Scripts strukturierter "programmieren" als in DCL. Die
Pipes sind übrigens kein Vorteil von Unix mehr, in VMS 7.1 sind die drin
(inclusive I/O-Redirection mit > und <).
> > Ein VMS-System kann locker hunderte, wenn nicht tausende von
> Benutzern
> > vertragen, sei es interaktive Terminal-User (auch sowas gibt's noch)
>
> > oder PC-Clients am Pathworks-Netz.
>
> Will ich nicht bestreiten, allerdings mag ich hier in den Raum
> stellen, daß das ein Unix-System genauso locker tut. Melde Dich bei
> nächster Gelegenheit mal auf ftp.cdrom.com an und sieh nach, der
> wievielte Benutzer Du dort gerade bist...
Entschuldigung, aber das ist nun wirklich kein Vergleich. Hunderte von
Benutzern mit FTP-Abfragen über's Internet zu befriedigen, wo das
Internet der Flaschenhals ist, ist was ganz anderes, als im
Fileserver-Betrieb Daten im FDDI oder Ethernet zur Verfügung zu stellen,
mit einem Delay, das so gering ist, daß nahezu lokale Antwortszeiten
erreicht werden - und *das* eben für hunderte von Benutzern.
Ich habe vor ein paar Jahren mal versucht, Leute zu finden, die mehr als
50 User auf einem Unix-System fahren. Erfolglos. Wir hatten damals eine
größere Anwendung auf einer VAX 6440 fahren, mit 250 bis 300 Usern und
dachten über einen Umstieg nach Unix nach... Gleichzeitig hatten wir
eine VAX 6610 als Pathworks-Server mit etwa derselben Anzahl an
teilweise recht aktiven PC-Clients - aber mit praktisch konstanten
Antwortszeiten. Beide VAXen waren damals schon veraltet und von der
reinen CPU-Leistung her kaum schneller als ein 486er (!) PC (ich habe
Benchmarks gefahren, ist wirklich so). Und auf der Alpha war's dann noch
mal schneller...
--
>Weiterhin ist das Systemmanagement eines VMScluster ein Kinderspiel im
>Vergleich zu einem Unix-Cluster. Es ist sehr schwierig hier alles
>aufzufuehren:
>30 min fuer eine vollstaendige Einbindung einer neuen Workstation. Booten
>uebers Netz. Umkonfiguration bei Plattenausfall im laufenden Betrieb
>innerhalb von Sekunden. Alle user finden die exakte Umgebung vor, egal wo
>sie sich Anmelden. U.V.A.M.
Ich will VMS nicht schlecht machen, aber das kann ich hier mit AIX
auch. Installation von der leeren Platte über NIM (network
installation management), ein "NewMachine" script (selbstgemacht),
einmal rdist, u. U. noch einmal rebooten, fertig. Gut, das mit der
Ausfallsicherheit kann ich nur im Prinzip, da wir nicht genug Geld
haben, um alle Platten zu spiegeln, aber das ist auch kein
Problem. Und: Ja, jeder Benutzer findet, bis auf so Sachen wie, daß
/tmp immer lokal ist, daß es explizit lokale /scratch Verzeichnisse
gibt, und daß dummerweise einige Programme aus Lizenzgründen nicht
überall laufen (ist mit Geld zu lösen), die gleiche Umgebung vor, egal
auf welcher Kiste sie sich einloggen.
Natürlich war das relativ viel Arbeit. Den NIM Server konfigurieren,
langes Nachdenken über Automounter, Distfile, zentrale Verwaltung von
Druckerkonfigurationen, inittabs, export files, usw. (Auch möglich, daß
das unter VMS einfacher ist).
Nebenbei: Das ist meiner Ansicht nach die einzige (natürlich im Prinzip,
wenn bei Sun der NIM anders heißt, bitte...) Möglichkeit, einen Haufen
Unix Maschinen mit endlichem Aufwand zu verwalten. Die Arbeit
skaliert, bis auf Harwareprobleme, nicht mehr mit der Anzahl der
Maschinen. _Das_ ist doch der Vorteil von Unix (und sicher auch VMS)
gegenüber den Windows Spielzeugen.
Tschüß,
Michael
--
Michael Staats, Theoretical Physics, Uni-GH Duisburg
email: mic...@thp.Uni-Duisburg.DE
<a href="http://WWW.thp.Uni-Duisburg.DE/">Click</a> me!
<a href="http://WWW.thp.Uni-Duisburg.DE/cuaix/cuaix.html">A c.u.aix archive</a>
> Warum? Ich habe nichts gegen einen sachlichen Austausch von Argumenten.
Meine Kenntnisse über VMS sind dazu zu gering.
> > Will ich nicht bestreiten, allerdings mag ich hier in den Raum
> > stellen, daß das ein Unix-System genauso locker tut. Melde Dich bei
> > nächster Gelegenheit mal auf ftp.cdrom.com an und sieh nach, der
> > wievielte Benutzer Du dort gerade bist...
>
> Entschuldigung, aber das ist nun wirklich kein Vergleich. Hunderte von
> Benutzern mit FTP-Abfragen über's Internet zu befriedigen, ...
Du hast Dich dort nicht eingeloggt, ich sehe es.
Nur mal so, ftp.cdrom.com gilt als der weltweit meistbeschäftigtste
FTP-Server im Internet. Er hat ein derzeitiges Userlimit von 2750
FTP-Usern in der Klasse `anonymous', hinzu kommt ein nicht ganz
unbeschäftigter WWW-Server (ok, der generiert weniger Prozesse), sowie
an die 20 Online-User, die auch nicht ganz ohne sind, dieweil die
diejenigen sind, die beispielsweise sackweise mirror-Scripts
laufenlassen. Falls Du mirror nicht kennst, das ist ein Perlscript,
und er ist bekannt/verrufen ob seines massiven VM-Verbrauchs (100 MB
pro laufendem Script sind nicht ungewöhnlich). Die Kiste hat wohl
derzeit 120 GB Platten dran und schaufelt im täglichen Durchschnitt
etwas um die 100 GB/Tag aufs Internet -- die sie zuvor auch von ihren
Platten gesucht haben will... Das ist eine konstante Last von mehr
als nur einem 10 Mbit Ethernetstrang (wobei der Durchschnitt nicht
viel sagt, dieweil die (US-)Nachtstunden eher wenig Last generieren,
so daß es in den Tagstunden ein mehrfaches ist).
Das alles ist eine einzige CPU, und laut Aussage derer, die dort einen
lokalen Account haben, ist die interaktive Antwortzeit zumindest
akzeptabel. ``Running `ps' on it is highly discouraged.'' meinte
neulich der Betreiber... ;-) (Bei 3000 und mehr Prozessen kein
Wunder.)
> Ich habe vor ein paar Jahren mal versucht, Leute zu finden, die mehr als
> 50 User auf einem Unix-System fahren.
Tut mir leid, die Systeme, die ich betreibe, sind auch alle kleiner.
Unser Firmenserver ist kürzlich abgelöst worden, weil ihm bei Aufgaben
wie großen Grafikjobs (Umrechnung ankommender Faxe) in der Tat die
Puste ausgegangen war -- ein 5 Jahre alter 486/33. :) Falls Du Deine
Unix-Erfahrungen mit sowas wie SVR3.2 gemacht hast, und das mit heuti-
gen Systemen vergleichst, dann wäre das wohl ungefähr so, wie wenn ich
VMS mit RSX-11 auf dem alten K1630 (PDP-11 Clone) in unserer Uni
vergleichen würde...
--
J"org Wunsch Unix support engineer
joerg_...@interface-business.de http://www.interface-business.de/~j
> Zunächst mal ist die Cluster-Technologie unter VMS wesentlich
> ausgereifter als in allen Unix-Derivaten, ...
...im übrigen denke ich, daß das vor allem der Tatsache anzulasten
ist, daß DEC selbst auf diesem Gebiet schon immer eine Vorreiterrolle
gespielt hat. Wenn DEC stattdessen auf Unix gesetzt hätte (was sie
früher nicht haben), hätten sie das sicher genausogut damit
hinbekommen.
Andere Hersteller haben einfach ihr Augenmerk auf andere Features
gelegt. Daraus den Anspruch zu erheben, daß ein proprietäres
Betriebssystem des Herstellers A (für das es logischerweise nur
Implementierungen des Herstellers A gibt, man also nicht vergleichen
kann) vom Design her besser ist als ein anderes Betriebssystem, das
von den Herstellern B, C und D implementiert worden ist (die unter-
einander je einen Satz von Gemeinsamkeiten als auch Spezialitäten
haben), halte ich für fragwürdig.
Ok, das war das letzte, was ich in diesem Thread von mir gegeben
habe...
Eine Katze ist ein Tier, ein Kuerbis eine Pflanze. Das ist der
wesentliche Unterschied. Erklaerst Du mir jetzt den wesentlichen
Unterschied zwischen VMS und Unix? Beides 32-bit-BS, beides multiuser-
und multitaskingfaehig. unterschiede liegen eher in den Details
(Filesystem, Sicherheit). Na?
Es gibt natuerlich eine Menge Unterschiede, von denen einige hier schon
erwaehnt wurden. Manche sind eher an der Oberflaeche (Kommandosprache,
Hilfesystem usw.), manche eher in der Tiefe (64-bit-Adressierung).
Manche bekommt nur der Systemverwalter richtig zu Gesicht.
Ich habe den Eindruck, dass man unter VMS weniger graue Haare bekommt,
wenn man als Systemverwalter ein einigermassen sicheres System
hinbekommen will. Das liegt vermutlich daran, dass VMS von Anfang mit
einem Augenmerk auf Sicherheit konzipiert wurde. Man hat einfach
von Haus aus (nicht durch aufgesetzte Werkzeuge) mehr Moeglichkeiten,
Zugriffsrechte und Quotas zu vergeben und Zugriffe u.ae. zu
kontrollieren.
Ein simples Beispiel: Natuerlich gibt es bei den meisten Unix-Versionen
eine Moeglichkeit, echte ACLs ("erweiterte ACLs") zu setzen, d.h.
fuer jede Datei (bei VMS geht's auch fuer Queues usw.) zu bestimmen,
welcher Benutzer wie zugreifen darf. (Ich meine nicht den relativ
primitiven Mechanismus ueber das user/group/world-Schema). Schon mal
probiert, die ACLs vernuenftig von einer Platte zur andern zu bringen
oder beim Backup zu sichern? Von einem andern Rechner aus (z.B. ueber
NFS)? Bei den Unix-Versionen, die ich kenne, geht's entweder gar nicht
oder es gibt Probleme.
VMS war auch von Anfang an - im Gegensatz zu Unix - ein System, bei dem
ein einziger Hersteller die Faeden in der Hand hielt. Die Konsequenz:
Bei Unix gibt's mehr Software, die dafuer geschrieben wurde (ich rechne
mal portierte Software nicht mit). Das gilt wohl mindestens fuer
kostenlose oder billige Software. VMS ist dafuer mehr aus einem Guss,
das macht sich z.B. bei gemischter Programmierung deutlich bemerkbar.
Beim Filesystem gibt es erhebliche Unterschiede. Es steckt eine
voellig verschiedene Philosophie dahinter. Ich bezweifle, dass die eine
oder andere "besser" ist, sie sind halt verschieden, und jeder Umsteiger
wird sich ueber das bisher fremde System ein bisschen wundern. Bei Unix
ist jede Datei eine Ansammlung von Bytes und nichts weiter. Alles,
was man sonst mit Dateien machen kann (Recordstruktur, Indizieren,
journal files ...)
ueberlaesst man dem Anwendungsprogramm. Bei VMS stehen dafuer
verschiedene Betriebssystemfunktionen zur Verfuegung. Dafuer braucht
VMS natuerlich die entsprechenden Informationen, und deshalb hat eine
Datei unter VMS normalerweise eine Fuelle von Eigenschaften (record size
usw.), die in der Directory abgespeichert werden.
Bei Unix sieht das Konzept also einheitlicher aus, bei VMS liefert
das Betriebssystem aber gleich eine Menge Funktionen mit, die sonst
ein Datenbanksystem zu erbringen hat.
Zu den Clusters wurde hier schon einiges gesagt. Das ist, soweit ich
sehe, die unbestrittene Staerke der VMS-Systeme.
Transaktionsverarbeitung gehoert auch dazu. Deshalb wird heute VMS
oft bei Boersen o.ae. eingesetzt, wo das System rund um die Uhr
verfuegbar sein muss.
Es gibt noch so ein paar Kleinigkeiten: Bei vielen Unix-Versionen
muss man den Kernel neu compilieren (!), um einen neuen Treiber
einzubinden. Das gibt's bei VMS natuerlich nicht, da uebersetzt keiner
irgendwelche Teile des Betriebssystems neu. Bei neueren Unixen (?)
ist das natuerlich teilweise auch schon anders.
Ueberhaupt habe ich den Eindruck, dass man auf beiden Seiten dabei
ist, von den Staerken des jeweils anderen Systems zu lernen. Unix
wird professioneller, VMS erhaelt zusaetzliche UNIX-aehnliche
Moeglichkeiten (z.B. Pipes auf der Kommandozeile). Ich
hoffe, dass mein Eindruck nicht taeuscht.
Es gibt noch viele Dinge, die man als Unterschiede anfuehren keonnte:
Prozesskonzept (bei Unix fuer jedes ausgefuehrte Programm ein neuer
Prozess, Prozesserzeugung wenig aufwendig), logische Namen, Links,
mehrere Versionen einer Datei, Netzwerkprotokolle ...
Vielleicht muss man sich die Geschichte der beiden Systeme anschauen,
um ein bisschen die Unterschiede zu verstehen. Fuer Unix spricht
hauptsaechlich der Preis und viel billige/kostenlose Software.
Ausserdem gibt's VMS nur fuer zwei Prozessortypen (VAX und Alpha).
Allerdings sind die verschiedenen Unix-Spielarten auch nicht so
kompatibel, wie man auf den ersten Blick denken koennte.
Auf dem PC gibt's jedenfalls VMS noch nicht.
> > Zunächst mal ist die Cluster-Technologie unter VMS wesentlich
> > ausgereifter als in allen Unix-Derivaten, ...
>
> ...im übrigen denke ich, daß das vor allem der Tatsache anzulasten
> ist, daß DEC selbst auf diesem Gebiet schon immer eine Vorreiterrolle
> gespielt hat. Wenn DEC stattdessen auf Unix gesetzt hätte (was sie
> früher nicht haben), hätten sie das sicher genausogut damit
> hinbekommen.
Naja, Unix kann man nicht so nach eigenen Gesichtspunkten modifizieren
wie VMS.
Unter der VMS-Cluster-Technologie gibt es den Distributed Lock Manager.
Und da der extrem performant funktioniert und eben *tief* in VMS
integriert ist, wird da einiges möglich. Z.B. kann man eine Platte
"zwischen" zwei Alphas hängen und beide haben direkten Zugriff auf die
Platte. Das ganze wird über dem DLM koordiniert. Unter Unix-Clustern muß
- das ist zumindest mein Kenntnisstand einer den Disk-Server spielen,
nur dieser hat direkten Zugriff.
> Andere Hersteller haben einfach ihr Augenmerk auf andere Features
> gelegt. Daraus den Anspruch zu erheben, daß ein proprietäres
> Betriebssystem des Herstellers A (für das es logischerweise nur
> Implementierungen des Herstellers A gibt, man also nicht vergleichen
> kann) vom Design her besser ist als ein anderes Betriebssystem, das
> von den Herstellern B, C und D implementiert worden ist (die unter-
> einander je einen Satz von Gemeinsamkeiten als auch Spezialitäten
> haben), halte ich für fragwürdig.
Ich habe nicht behauptet, daß VMS generell besser ist als Unix - das
wäre auch vermessen, denn ein bedingungsloses "besser" gibt es nicht -
sondern die Zwecke aufgezählt, für die VMS IMHO besser geeignet ist als
Unix. Jemand, der Unix besser kennt als ich kann sicherlich auch einige
Sachen aufzählen, für die Unix viel besser geeignet ist.
Und noch ein Wort zu proprietären Betriebssystemen: Warum meckert alle
Welt über proprietäre Software und kauft gleichzeitig massenhaft
Microsoft-Software? Damit belügt man sich doch selbst. Meine
Quintessenz: Proprietär muß nicht schlecht sein. Zumal die
hersteller-spezifischen Unixe auch proprietär sind.
> Ok, das war das letzte, was ich in diesem Thread von mir gegeben
> habe...
Schade...
> Natürlich war das relativ viel Arbeit. Den NIM Server konfigurieren,
> langes Nachdenken über Automounter, Distfile, zentrale Verwaltung von
> Druckerkonfigurationen, inittabs, export files, usw. (Auch möglich,
> daß
> das unter VMS einfacher ist).
Und *genau das* ist der Unterschied. Unter VMS läßt man - von Prinzip
her - eine DCL-Prozedur namens cluster_config.com laufen, beantwortet
ein paar Fragen und gut is'.
Exportieren? Für was? Ich stelle einfach einen Shadow-Set aus zwei
Platten her, die an verschiedenen Rechnern hängen, die "nur" über FDDI
verbunden sind. Wie mache ich das? Mount-Kommando mit den richtigen
Qualifiern. Nebenbei ist jede Platte natürlich an zwei Rechner
angeschlossen, die direkten Zugriff darauf haben.
Natürlich muß man sich über das *Konzept* hochredundanter Systeme sehr
klar sein - ich werde darüber nächstes Jahr beim DECUS-Symposium in
Karlsruhe einen Vortrag halten. Aber die Realisierung ist dann straight
forward.
Das ist so nicht korrekt. Auch auf den Sun clustern unter Solaris wird
ein DLM verwendet, wahlweise der von Sun oder eventuell auch der von
Oracle. In einem Sun cluster muss keiner den Fileserver spielen, alle
Systeme die sich im cluster befinden haben gleichwertigen Zugriff auf
alle filesystems, die vom DLM verwaltet werden.
--
Udo Munk - http://www.umnet.de/
No working email address provided in newsgroups anymore, sorry for the
inconvenience. If you definitely have to email me please look it up on
the web page mentioned above.
Hm, das letze Mal das ich mit VMS gearbeitet habe ist etwa 12 Jahre her,
keine Ahnung wie das heute aussieht. Aber so wie du das hier beschreibst
funktioniert das nicht anders als bei Sun Solaris clustern auch.
Cluster manager aufrufen, paar Fragen beantworten und Systeme in
den cluster aufnehmen, fertig.
: Exportieren? Für was? Ich stelle einfach einen Shadow-Set aus zwei
: Platten her, die an verschiedenen Rechnern hängen, die "nur" über FDDI
: verbunden sind. Wie mache ich das? Mount-Kommando mit den richtigen
: Qualifiern. Nebenbei ist jede Platte natürlich an zwei Rechner
: angeschlossen, die direkten Zugriff darauf haben.
Hoert sich ganz genauso an wie das auf Solaris clustern auch gemacht wird.
Das ist zwar auch mein Kenntnisstand, entscheidend ist aber, dass die
heutigen Netzwerkfilesystem unter Unix sehr grosse Puffer auf der Platte
erlauben, so dass beide Systeme einen schnellen Zugriff auf die Daten haben
koennen.
so long
MUFTI
--
Das Video und Lebhaftigkeit-Bibleotheken jedes enthaelt AVI (Film)Akten,
ohne irgendeinen subcategory-Zusammenbruch
(aus einem Softwarehandbuch, Stichwort: animation)
Wie kommt ihr auf die wirre Idee, Unix waere ein 32-Bit Betriebssystem ?
Es gibt Unixe auf Prozessoren mit 20-Bit-Architektur, welche mit
64-Bit-Architektur und warum mir der Debugger auf der NEC-SX4 unter SUPER UX
einen Pointer von 128 Bit Laenge an den Kopf wirft, wuerde mich auch mal
interessieren 8-)
Nur weil die meisten Prozessoren gerade 32 Bit arbeiten und Unix die viele
verschiedene Prozessoren unterstuetzt wird Unix noch nicht zu einem
32-Bit Betriebssystem.
Eine aehnliche Loesung ist zB. rdist
>Exportieren? Für was? Ich stelle einfach einen Shadow-Set aus zwei
>Platten her, die an verschiedenen Rechnern hängen, die "nur" über FDDI
>verbunden sind. Wie mache ich das? Mount-Kommando mit den richtigen
>Qualifiern.
Ah ja. Und dann kann Lieschen Hacker, die auch irgendwo im FDDI angeschlossen
ist, deine Platte auch Mounten ? Wenn du keine Zugriffsrechte fuer dein
Filesystem vergibst (und was ist exportieren im Prinzip anderes), dann
kannst Du so ein Filesystem nur hardwaremaessig begrenzt aufbauen.
Ausserdem die Frage: Macht das Ganze auch Sinn fuer einen Campus voll
Maschinen ?
Wobei man sagen muss, dass VMS auf dem Prinzip "Security ueber
Geheimniskraemerei" basiert und es vor Unzeiten einen Einbruch bei
DEC gab, bei dem die Hacker auch schreibenden Zugriff auf den VMS-Sourcecode
hatten 8-(
Der Eindruck, dass man unter VMS securitymaessig weniger graue Haare
kriegt, kann also ganz schoen teuschen ...
>Ein simples Beispiel: Natuerlich gibt es bei den meisten Unix-Versionen
>eine Moeglichkeit, echte ACLs ("erweiterte ACLs") zu setzen, d.h.
>fuer jede Datei (bei VMS geht's auch fuer Queues usw.) zu bestimmen,
>welcher Benutzer wie zugreifen darf. (Ich meine nicht den relativ
>primitiven Mechanismus ueber das user/group/world-Schema). Schon mal
>probiert, die ACLs vernuenftig von einer Platte zur andern zu bringen
>oder beim Backup zu sichern?
Ja. So was macht man z.B. mit AFS, das es fuer alle ueblichen UNIXe gibt und
dem dazugehoerenden Backup ....
>Zu den Clusters wurde hier schon einiges gesagt. Das ist, soweit ich
>sehe, die unbestrittene Staerke der VMS-Systeme.
>Transaktionsverarbeitung gehoert auch dazu.
Du hast vermutlich noch nie was von DCE/DFS gehoert ?
>Bei neueren Unixen (?)
>ist das natuerlich teilweise auch schon anders.
Ich habe auch keine Ahnung, wer das zuerst erfunden hat 8-)
>Vielleicht muss man sich die Geschichte der beiden Systeme anschauen,
>um ein bisschen die Unterschiede zu verstehen. Fuer Unix spricht
>hauptsaechlich der Preis und viel billige/kostenlose Software.
>Ausserdem gibt's VMS nur fuer zwei Prozessortypen (VAX und Alpha).
>Allerdings sind die verschiedenen Unix-Spielarten auch nicht so
>kompatibel, wie man auf den ersten Blick denken koennte.
Klar, wenn DEC in seine UNIXe immer nichtstandisierte Erweiterungen
einbaut 8-)
>Auf dem PC gibt's jedenfalls VMS noch nicht.
Was ? Sogar die alten IBM-Mainframes gibts schon lange als
PC-Einsteckkarte 8-)
> Kann mir mal einer erklaeren, welchen Mailer Ihr benutzt?
>
> Der groesste Teil Eurer Mails ist verstuemmelt.
>
> Und zu UNIX und VMS: das ist wie Auto A und Auto B.
>
> Aber bevor Ihr Euch ueber die Unterschiede zwischen A und B
> unterhaltet, wie waere es, wenn Ihr Euch einen gescheiten
> Mailer zulegen wuerdet?
Fragt sich, welcher Mailer "gescheit" ist...
Ich vermute naemlich, daß es um die Umlaute geht. Nach meinem
Kenntnisstand kann die naemlich jeder Mailer darstellen, der MIME kann
und ich ging eigentlich davon aus, dass fast jeder das mittlerweile kann
(zumindest hat sich noch nie einer beschwert) und benutze daher -
normalerweise - Umlaute.
--
Manfred Haertel mailto:Manfred...@t-online.de
http://home.t-online.de/home/Manfred.Haertel
Es gibt eine Linux-HOWTO mit dem Titel "VMS to Linux". Da finden sich
sicher
einige Hinweise.
==> http://www.idiscover.co.uk/linux/linuxdoc/HOWTO/HOWTO-INDEX-3.html
...Rolf
--
.----------------------------------------------------------.
| Rolf Niepraschk -- Physikalisch-Technische Bundesanstalt |
| Abbestr. 2-12; D-10587 Berlin, Germany |
| Tel/Fax: ++49-30-3481-316/490, email: niepr...@ptb.de |
`----------------------------------------------------------'
'tin' ist etabliert, Linux ist ein UNIX, und diese Gruppe ist die einzige
mir bekannte, wo derart verstuemmelte Posts auftauchen.
Gruss
--
------------------------------------------------------------------------------
Ruediger Schuetz Phone/Fax: 00 49-89-65 81 92
Edlinger Platz 4
81543 Muenchen Ruediger...@Munich.Netsurf.DE
Germany
------------------------------------------------------------------------------
: Ausserdem die Frage: Macht das Ganze auch Sinn fuer einen Campus voll
: Maschinen ?
Aber sicher: Automounter bzw. AMD. Ein Beispiel. Du hast z.B. 10.000 Systeme,
sys00000 bis sys1000000 (beliebige Namen sind okay).
Bei geeigneter Einrichtung greifst Du auf /net/sys05342/subdir/some zu.
NFS ist sicherlich bekannt, wird aber leider oft nur in der primitivsten
Form benutzt (statische Eintraege in /etc/fstab).
Der richtige Hit ist NFS via Automounter, kombiniert mit NIS. Der Automounter
ist quasi eine dynamische Ergaenzung zur fstab (Mount on Demand), und was
von wo zu mounten ist (und anderes, wie Authentifizierung) wird ueber NIS
verteilt.
VMS ist gut, aber UNIX ist auch nicht von Pappe.
Mit UNIX Clustern kann man auch durchaus seinen Frieden schliessen. Uebel
war seinerzeit die Behauptung einiger Hersteller, es sei vergleichbar oder
gar besser mit/als VMS Cluster. Das war sicherlich Unfug.
Es funktioniert gaenzlich anders, leistet aber grob aehnliches. In Teilen
leistet es sogar mehr (!!!). Naemlich automatisches Hochfahren einer
Applikation auf einem anderen Cluster Knoten (Failover).
Zusammenfassung: VMS ist saugut, und UNIX war vor 10 Jahren ein trauriger
Hack. Ein vernuenftiges UNIX ist aber heute durchaus ernstzunehmen.
VMS ist auch in mancher Hinsicht ein Dino. DCL ist z.B. eine Schande gegen
ksh, die Sprache hat nicht einmal das rudimentaerste.
Die ksh93 hat von VMS gelernt, kann Images in den Prozess der Shell mappen,
fork und exec sind kein Thema mehr. Die dtksh ist Visual Basic, Fenster
Operationen (X11) aus einer Shell heraus.
Vorschlag: in UNIX einarbeiten (ja, das ist sperrig, und der vi ist Mist),
nach einer Woche ist das groebste geschafft. Dann mit offenen Augen
umsehen. Ich wollte heute kein VMS mehr.
: Aber sicher: Automounter bzw. AMD. Ein Beispiel. Du hast z.B. 10.000 Systeme,
: sys00000 bis sys1000000 (beliebige Namen sind okay).
: Bei geeigneter Einrichtung greifst Du auf /net/sys05342/subdir/some zu.
: Der richtige Hit ist NFS via Automounter, kombiniert mit NIS. Der Automounter
: ist quasi eine dynamische Ergaenzung zur fstab (Mount on Demand), und was
: von wo zu mounten ist (und anderes, wie Authentifizierung) wird ueber NIS
: verteilt.
ja, aber zumindest so wie ich das NIS kenne, kann jetzt jeder an die
NIS-Maps, insbeondere "passwd" kommen. D.h. mein schoenes Shadow-PW-System
nuetzt mir gar nix. Insbesondere, wenn ich verschiedene Unix-Derivate
(AIX 3.25, 4.x -- Solaris 2.5 , 2.6, Linux, HP UX...) habe. Dann kommen
doch glatt noch einige PC-Freaks mit Win95/NT und Chamaelon und aehnlichem.
Das ganze kann auch Aerger machen. Zumal die NFS-Pakete unverschluesselt
uebers Netz wandern, kann man also wunderbar abhorchen.
Wer ansatzweise Loesungen fuer diese Probleme kennt, moege mich bitte
darauf hinweisen.
mfg,
peddy
--
====================================================================+
_\_|_/__ I
/ o o \ Andreas Peters I
| I | ============== I
| \_____ / e-mail: pet...@math.uni-hamburg.de I
| url : http://www.math.uni-hamburg.de/home/peddy I
| eddy Tel. : +49-40-69692847 I
====================================================================+
> Wobei man sagen muss, dass VMS auf dem Prinzip "Security ueber
> Geheimniskraemerei" basiert und es vor Unzeiten einen Einbruch bei
> DEC gab, bei dem die Hacker auch schreibenden Zugriff auf den
> VMS-Sourcecode
> hatten 8-(
Von wegen Geheimniskrämerei. Den Source-Code kriegt man auf Wunsch auf
CD und dann gibt es noch die VMS-Bibel, das Buch "VMS Internals and Data
Structures", in denen der VMS-Kernel nun wirklich bis auf's letzte Bit
erklärt wird. Was Äquivalentes für irgendein Unix ist mir nicht bekannt!
> >Exportieren? Für was? Ich stelle einfach einen Shadow-Set aus zwei
> >Platten her, die an verschiedenen Rechnern hängen, die "nur" über
> FDDI
> >verbunden sind. Wie mache ich das? Mount-Kommando mit den richtigen
> >Qualifiern.
>
> Ah ja. Und dann kann Lieschen Hacker, die auch irgendwo im FDDI
> angeschlossen
> ist, deine Platte auch Mounten ? Wenn du keine Zugriffsrechte fuer
> dein
> Filesystem vergibst (und was ist exportieren im Prinzip anderes), dann
>
> kannst Du so ein Filesystem nur hardwaremaessig begrenzt aufbauen.
Nein, denn natürlich gibt es eine Security. Erstens gibt es ein Cluster
Password, mit dem der Eintritt ins Cluster geschützt wird, zum anderen
braucht man zum Mounten eben die entsprechenden Privilegien.
> Ausserdem die Frage: Macht das Ganze auch Sinn fuer einen Campus voll
> Maschinen ?
Jein. Es gibt unter VMS-Clustern die Möglichkeit des Remote Boot und
mehr als ein Ethernet ist dazu nicht notwendig, FDDI ist natürlich
besser.
Allerdings sollten nicht mehr als ca. 100 Knoten im Cluster sein, weil
das System ansonsten zu komplex wird.
In article <666mhn$ijt$1...@infosun2.rus.uni-stuttgart.de>,
rusm...@helpdesk.rus.uni-stuttgart.de (Joerg Scheurich aka MUFTI) writes:
|>>Unter der VMS-Cluster-Technologie gibt es den Distributed Lock Manager.
|>>Und da der extrem performant funktioniert und eben *tief* in VMS
|>>integriert ist, wird da einiges möglich. Z.B. kann man eine Platte
|>>"zwischen" zwei Alphas hängen und beide haben direkten Zugriff auf die
|>>Platte. Das ganze wird über dem DLM koordiniert. Unter Unix-Clustern
|>muß
|>>- das ist zumindest mein Kenntnisstand einer den Disk-Server spielen,
|>>nur dieser hat direkten Zugriff.
|>
|>Das ist zwar auch mein Kenntnisstand, entscheidend ist aber, dass die
|>heutigen Netzwerkfilesystem unter Unix sehr grosse Puffer auf der Platte
|>|>erlauben, so dass beide Systeme einen schnellen Zugriff auf die Daten
|>haben
|>koennen.
|>
|>so long
|>MUFTI
|>
|>--
|>Das Video und Lebhaftigkeit-Bibleotheken jedes enthaelt AVI (Film)Akten,
|>ohne irgendeinen subcategory-Zusammenbruch
|> (aus einem Softwarehandbuch, Stichwort: animation)
|>
Ein recht wichtige Frage: Was passiert mit den Daten, wenn dieser
gepufferte Bereich noch nicht auf Platte geschrieben wurde und ein netter
Benutzer den RESET-Knopf drueckt?
Mein Vermutung: die Daten sind futsch. Bei VMS nicht. Punkt.
Eberhard
In article <666ohl$li7$1...@infosun2.rus.uni-stuttgart.de>,
rusm...@helpdesk.rus.uni-stuttgart.de (Joerg Scheurich aka MUFTI) writes:
|>>Ich habe den Eindruck, dass man unter VMS weniger graue Haare bekommt,
|>>wenn man als Systemverwalter ein einigermassen sicheres System
|>>hinbekommen will. Das liegt vermutlich daran, dass VMS von Anfang mit
|>>einem Augenmerk auf Sicherheit konzipiert wurde.
|>
|>Wobei man sagen muss, dass VMS auf dem Prinzip "Security ueber
|>Geheimniskraemerei" basiert und es vor Unzeiten einen Einbruch bei
|>DEC gab, bei dem die Hacker auch schreibenden Zugriff auf den
|>VMS-Sourcecode
|>hatten 8-(
|>
|>Der Eindruck, dass man unter VMS securitymaessig weniger graue Haare
|>kriegt, kann also ganz schoen teuschen ...
|>
|>>Ein simples Beispiel: Natuerlich gibt es bei den meisten Unix-Versionen
|>>eine Moeglichkeit, echte ACLs ("erweiterte ACLs") zu setzen, d.h.
|>>fuer jede Datei (bei VMS geht's auch fuer Queues usw.) zu bestimmen,
|>>welcher Benutzer wie zugreifen darf. (Ich meine nicht den relativ
|>>primitiven Mechanismus ueber das user/group/world-Schema). Schon mal
|>>probiert, die ACLs vernuenftig von einer Platte zur andern zu bringen
|>>oder beim Backup zu sichern?
|>
|>Ja. So was macht man z.B. mit AFS, das es fuer alle ueblichen UNIXe gibt
|>und
|>dem dazugehoerenden Backup ....
AFS gehoert Transarc und ist proprietaer. Nur Transarc entscheidet, ob AFS
fuer ein bestimmtes Unix-OS zur Verfuegung steht oder nicht.
|>
|>>Zu den Clusters wurde hier schon einiges gesagt. Das ist, soweit ich
|>>sehe, die unbestrittene Staerke der VMS-Systeme.
|>>Transaktionsverarbeitung gehoert auch dazu.
|>
|>Du hast vermutlich noch nie was von DCE/DFS gehoert ?
Z.B. SGI will pro Client DCE/DFS-Lizenz mehrere KiloDM. DCE/DFS ist kein
Teil von Unix. DCE/DFS gibt es auch fuer VMS (NFS auch).
|>
|>>Bei neueren Unixen (?)
|>>ist das natuerlich teilweise auch schon anders.
|>
|>Ich habe auch keine Ahnung, wer das zuerst erfunden hat 8-)
|>
|>>Vielleicht muss man sich die Geschichte der beiden Systeme anschauen,
|>>um ein bisschen die Unterschiede zu verstehen. Fuer Unix spricht
|>>hauptsaechlich der Preis und viel billige/kostenlose Software.
Das ist nicht mehr richtig. Heutzutage ist Unix-Software auch "teuer". Ich
kann, und das wollen die wenigsten wahr haben, die allermeisten Programme
auch fuer VMS kriegen (Stichwort DECUS):
TCL/TK, Ghostscript/Ghostview, XV, CDWRITE, Gnuplot, Imagemagick ,Povray
um ein paar Programme zu nennen.
|>>Ausserdem gibt's VMS nur fuer zwei Prozessortypen (VAX und Alpha).
|>>Allerdings sind die verschiedenen Unix-Spielarten auch nicht so
|>>kompatibel, wie man auf den ersten Blick denken koennte.
Genau: Bekomme ich IRIX fuer Intel? Alle Unix-Derivate sind proprietaer.
Selbst Linux gehoert jemanden, oder?
|>
|>Klar, wenn DEC in seine UNIXe immer nichtstandisierte Erweiterungen
|>einbaut 8-)
|>
|>>Auf dem PC gibt's jedenfalls VMS noch nicht.
|>
|>Was ? Sogar die alten IBM-Mainframes gibts schon lange als
|>PC-Einsteckkarte 8-)
|>
|>so long
|>MUFTI
|>--
|>Das Video und Lebhaftigkeit-Bibleotheken jedes enthaelt AVI (Film)Akten,
|>ohne irgendeinen subcategory-Zusammenbruch
|> (aus einem Softwarehandbuch, Stichwort: animation)
|>
Eberhard
Wenn ich seh, wie sich meine Kollegen mit der Verwaltung eines
Unix-Systems plagen muessen, bleib ich bei meiner Aussage.
Es geht z.B. um Zugriffskontrolle und solche Dinge.
>
> Du hast vermutlich noch nie was von DCE/DFS gehoert ?
Doch. Aber was hat das mit Clustern zu tun? Ich meine nicht
irgendein verteiltes Filesystem, das bezeichne ich nicht als
Cluster.
Es gab vor kurzem eine Gegenueberstellung von verschiedenen
Betriebssystemen, weiss leider nicht mehr wo. Bei den Clustern
lag VMS eindeutig vorn.
Aber davon abgesehen: Ich moechte z.B. mindestens zwei Rechner
betreiben (wegen Ausfallsicherheit), die auf gemeinsam genutzte
Daten auf einem Raid-System direkt ueber SCSI zugreifen (wenn einer
ueber den andern zugreift, hilft mir das nichts. Natuerlich kann's
auch eine gewoehnliche Platte sein, aber das ist vielleicht nicht der
typische Anwendungsfall). Was hilft denn da DCE/DFS?
Das ist natuerlich nicht die einzige, vielleicht nicht einmal die
prominenteste Cluster-Anwendung. Aber es ist die, die wir hier
mit grossem Nutzen anwenden koennten, haetten wir VMS auf unseren
Workstations (aber die sind von HP).
Also: Ich will hier gar nicht alle Unix-Fans zu VMS-Fans konvertieren,
aber ich will erst mal ein echtes Cluster sehen, das die Moeglichkeiten
alle bietet, die VMS-Cluster bieten, das zuverlaessig funktioniert und
mit ertraeglichem Aufwand zu verwalten ist (z.B.: Was passiert, wenn
ich irgendwann auf die Idee komme, das Cluster aufzuloesen und die
Maschinen nur noch ueber ein verteiltes Filesystem zu koppeln?).
>
> Klar, wenn DEC in seine UNIXe immer nichtstandisierte Erweiterungen
> einbaut 8-)
Das liegt nicht nur an DEC. Sind etwa die Betriebssysteme von Sun, HP,
IRIS wirklich voll kompatibel?
Und ausserdem sind manche Erweiterungen
nur dazu da, echte zusaetzliche Moeglichkeiten zu schaffen
(z.B. TruCluster oder wie das heisst), die sonst einfach fehlen.
Bei HP ist das z.B. der beruehmt-beruechtigte SAM, der die
Systemverwaltung erleichtern soll. Oder eine spezielle Backupsoftware.
(Backup ist auch so eine Staerke von VMS, da bekommt man mit
dem Betriebssystem gleich was Gescheites mitgeliefert).
Also nochmal: Ich will keinem die Freude an seinem Unix vermiesen.
Ich muss ja manchmal selbst damit arbeiten, weil irgendein
Softwarepaket halt fuer die HP-UX-Systeme angeschafft wurde.
Aber es entspricht auch nicht gerade so meiner Vorstellung vom
idealen Betriebssystem.
P.S.: Zu den anderen Punkten haben andere schon kompetentere Beitraege
geliefert, drum spar ich mir, darauf einzugehen (z.B. DCE/DFS auf VMS).
Man kann dann immer noch mehrere Cluster aufbauen. Ich seh auch auf
unserem Campus nicht, dass man das ueberhaupt machen will. Ich
glaube, das ist nicht die Anwendung von Clustern. Ich sehe eher
den Aspekt der hohen Verfuegbarkeit (dazu brauche ich keine paartausend
Maschinen - oder?) und der gemeinsamen Verwaltung, aber das ist ja
bei einem "Campus voll Maschinen" auch nicht unbedingt erwuenscht.
Und pro selbstaendiger organisatorischer Einheit (z.B. Institut
oder Abteilung) braucht man meistens gar nicht sooooooooooo viele
Maschinen.
>Von wegen Geheimniskrämerei. Den Source-Code kriegt man auf Wunsch auf
>CD und dann gibt es noch die VMS-Bibel, das Buch "VMS Internals and Data
>Structures", in denen der VMS-Kernel nun wirklich bis auf's letzte Bit
>erklärt wird. Was Äquivalentes für irgendein Unix ist mir nicht bekannt!
Hmmm, das klingt so nach "The design and implementation of the Unix
operating system" (Bach)...
Den Source bekommt man leider im Normalfall nicht, das stimmt.
gert
--
Wege entstehen, wenn wir sie gehen. | gert doering
Vielleicht sollte ich meinen Beobachterposten | ge...@greenie.muc.de
an der Strassenkreuzung aufgeben. | 2:2480/55.4
Zumindest die Kunden in Forschung und Lehre koennen von SUN die
Solaris-Sourcen bekommen. Ich kenne allerdings die Bedingungen
nicht, aber teuer ist es nicht. (<1k DM)
Gruss
wo
--
Werner Olschewski Phone: 02241-14-2757
Sysa...@FIT-MMK.GMD email: werner.o...@gmd.de
Never trust a short-haired guru.
> Mein Vermutung: die Daten sind futsch. Bei VMS nicht. Punkt.
Das ist doch aber immer ein Tradeoff zwischen Sicherheit und
Geschwindigkeit. Klassisches NFS schreibt synchron und ist damit
relativ langsam im Schreiben. NFSv2 bietet optional asynchrones
Schreiben, bei dem der Client sich dann über den Abschluß der
Operation informieren lassen kann.
Ich kann auch jeglichen Schreibpuffer ganz sein lassen, dann bin ich
halt lahmar***ig wie ein altes MS-DOS.
Es gibt eine ganze Reihe von Lösungen, das Problem dahingehend zu
lösen, daß man abgesicherte Pufferspeicher benutzt (Prestoserve zum
Beispiel), die selbst bei Stromausfall noch batteriegepuffert
speichern.
Außerdem: wenn bei Dir Nutzer so mir nichts, dir nichts Resetknöpfe
drücken (können), dann hast Du ein ganz anderes Problem. :-))
(Jaja, ich hatte versprochen, mich nicht mehr zu äußern, ich weiß,
aber so viel an Mißinformation war mir zu viel.)
: ja, aber zumindest so wie ich das NIS kenne, kann jetzt jeder an die
: NIS-Maps, insbeondere "passwd" kommen. D.h. mein schoenes Shadow-PW-System
: nuetzt mir gar nix. Insbesondere, wenn ich verschiedene Unix-Derivate
: (AIX 3.25, 4.x -- Solaris 2.5 , 2.6, Linux, HP UX...) habe. Dann kommen
: doch glatt noch einige PC-Freaks mit Win95/NT und Chamaelon und aehnlichem.
: Das ganze kann auch Aerger machen. Zumal die NFS-Pakete unverschluesselt
: uebers Netz wandern, kann man also wunderbar abhorchen.
: Wer ansatzweise Loesungen fuer diese Probleme kennt, moege mich bitte
: darauf hinweisen.
Unter VMS laufen auch alle Pakete unverschluesselt ueber das Netz. Es redu-
ziert sich darauf, dass man keine PCs am Netz haben sollte :)
Loesungen gegen Password Cracking sind NIS+, Kerberos, oder besser noch
Aufklaerung der Anwender.
Wer physikalischen Zugriff zum Netzwerk erlaubt (PCs), darf sich nicht
wundern, dass es Sicherheitsluecken gibt.
Es tun sich da noch ganz andere Luecken auf: Lopez hat sich bei Opel Kisten
mit Printouts anfertigen lassen, wie dusselig. Mit einem Laptop koennte
so einer jeden Tag einige GigaByte Daten mit nach hause nehmen.
Kurzum: es bringt nichts, die eine Schraube 'Password File' festzuziehen,
und gleichzeitig den Mitarbeitern Laptops zu verpassen.
Eben. Ich wollte eigentlich vor allen Dingen darauf hinaus, daß Disk
Serving im Netzwerk mit VMS-Cluster quasi auch noch mal "umsonst"
mitkommt - inclusive Remote Boot. Das macht natürlich auch die
Administration einfacher, weil Software-Pakete nur einmal installiert
werden müssen. Wobei das gar nicht so viel besser ist, als das, was im
Unix-Bereich - dort ganz unabhängig von Cluster - auch geht.
Wenn man *Hochverügbarkeit* will, sollte man IMHO über ca. ein halbes
Dutzend Knoten im Cluster nicht hinausgehen. Unser Rechenzentrum besteht
etwa aus 4 Knoten und zieht nahezu alle Register, was die
Redundanz-Möglichkeiten von VMS-Clustern angeht und das ist eine
angemessene Größe.
> |>>Vielleicht muss man sich die Geschichte der beiden Systeme
> anschauen,
> |>>um ein bisschen die Unterschiede zu verstehen. Fuer Unix spricht
> |>>hauptsaechlich der Preis und viel billige/kostenlose Software.
>
> Das ist nicht mehr richtig. Heutzutage ist Unix-Software auch "teuer".
> Ich
> kann, und das wollen die wenigsten wahr haben, die allermeisten
> Programme
> auch fuer VMS kriegen (Stichwort DECUS):
>
> TCL/TK, Ghostscript/Ghostview, XV, CDWRITE, Gnuplot, Imagemagick
> ,Povray
> um ein paar Programme zu nennen.
In der Tat...
Wenn es nur darum geht, viel billige oder kostenlose Software zu
kriegen, dann ist Windows 3.1 (nicht 95 oder NT) das beste
Betriebssystem der Welt...
Und der Hinweis auf DECUS ist gar nicht so verkehrt... ;-)
(VMS-CLI)
> Pipes sind übrigens kein Vorteil von Unix mehr, in VMS 7.1 sind die drin
> (inclusive I/O-Redirection mit > und <).
Falsch. Seit VMS 5.5 (ca 1991).
--
\ Ulli 'Framstag' Horlacher \ BelWue-Koordination \ fram...@belwue.de \
\ Universitaet Stuttgart \ Allmandring 30 \ D-70550 Stuttgart \ Germany \
\ SAFT://saft.belwue.de/framstag \ HTTP://www.belwue.de/ \
\ "X.500: Security through Complexity" - Juergen G. \
> (VMS-CLI)
> > Pipes sind übrigens kein Vorteil von Unix mehr, in VMS 7.1 sind die
> drin
> > (inclusive I/O-Redirection mit > und <).
>
> Falsch. Seit VMS 5.5 (ca 1991).
Ja, Du hast recht: In *VMS* sind die schon länger drin, nämlich in der
Posix-Shell. Und außerdem gab es Third Party Produkte, die das konnten.
In DCL sind sie aber erst seit VMS 7.1.
: Zumindest die Kunden in Forschung und Lehre koennen von SUN die
: Solaris-Sourcen bekommen. Ich kenne allerdings die Bedingungen
: nicht, aber teuer ist es nicht. (<1k DM)
US$100 kostet der Spass, bei einer gleichzeitigen Bestellung von
"irgendetwas anderem" bei Sun ist es kostenlos. Dabei gibt es uebrigens
auch SunOS 4.1.4-Sources und Sources fuer die x86-Version von Solaris.
Was mir noch niemand bei Sun beantworten konnte ist, ob man mit einem Vertrag
Sourcecode fuer mehrere Systeme gleichzeitig beantragen kann ;-).
Da es hier ja eigentlich um Unix vs. VMS geht, eine Frage von mir an die
VMS-Gurus: in welcher Sprache ist VMS implementiert ? Ich kann mich dunkel
dran erinnern, dass fruehe VAX-Versionen groesstenteils in Macro32
programmiert waren, wie sieht das auf dem Alpha aus ?
ciao,
Michael Engel (en...@unix-ag.uni-siegen.de)
: Da es hier ja eigentlich um Unix vs. VMS geht, eine Frage von mir an die
: VMS-Gurus: in welcher Sprache ist VMS implementiert ? Ich kann mich dunkel
: dran erinnern, dass fruehe VAX-Versionen groesstenteils in Macro32
: programmiert waren, wie sieht das auf dem Alpha aus ?
VMS ist ueberwiegend in Macro 32 und BLISS implementiert. Auf der Alpha
gibt es fuer beide (!) Compiler.
Macro 32 und BLISS mit Builtins muss ggfs. etwas gefixt werden, dann
compiliert es. Es gibt auch einen native Macro 64, und der DEC C Compiler
kann mittlerweile Builtins.
Die Sprache der Wahl ist mittlerweile DEC C, also fuer Neuimplementierungen.
Macro 32 und Bliss sind also Altlasten.
Auf der VAX gab es noch einige Exoten, der Password Generator war z.B. in
PL/1 implementiert. Keine Ahnung, wie das heute ist.
>Gert Doering (ge...@greenie.muc.de) wrote:
>: Den Source bekommt man leider im Normalfall nicht, das stimmt.
>Zumindest die Kunden in Forschung und Lehre koennen von SUN die
>Solaris-Sourcen bekommen. Ich kenne allerdings die Bedingungen
>nicht, aber teuer ist es nicht. (<1k DM)
Das meinte ich mit "im Normalfall" -- das Hauptproblem bei dem Angebot von
SUN ist das Non-Disclosure-Agreement ("rede nicht mal drueber, was Du
da gesehen hast").
> Ja, Du hast recht: In *VMS* sind die schon länger drin, nämlich in der
> Posix-Shell. Und außerdem gab es Third Party Produkte, die das konnten.
Frams ist also offenbar Author eines solchen Third Party Produkts. Ich
hab damals auch sein ORAKEL-LOGIN benutzt. :-)
Da wurde manches Unix-kompatibel (zB cd).
--
| J"urgen Dollinger | mailto:jue...@magrathea.stud-verwaltung.uni-ulm.de |
| Universit"at Ulm | http://www.stud-verwaltung.uni-ulm.de/people/juergen/ |
| Black holes are where God divided by zero! |
Dein tin ist auch in etwa so alt wie VMS News 1.25. Allerdings hat
sich bei tin in letzter Zeit so richtig viel getan. Wenn der String
"1.4" in der Versionsnummer auftaucht sprechen wir uns wieder.
Juergen der grad mal wieder VMS News anwirft, aber eigentlich inzwischen
tin gewohnt ist.
> Vorschlag: in UNIX einarbeiten (ja, das ist sperrig, und der vi ist Mist),
> nach einer Woche ist das groebste geschafft. Dann mit offenen Augen
> umsehen. Ich wollte heute kein VMS mehr.
Wenn man erstmal in vi eingearbeitet ist, dann wuenscht man sich keinen
anderen editor mehr ... wer etwas mehr Komfort moechte, der nimmt vim.
Außerdem ist vi _der_ Standard Editor auf allen Unix Platformen ...
Ich frage mich, wie man Server Systeme ohne X11 oder im Netzwerk via
telnet administrieren moechte, wenn man vi nicht beherrscht ...
Oder wenn man zum Kunden faehrt ... die haben meistens generische
Maschinen...
--
Andreas Klemm
powered by ,,symmetric multiprocessor FreeBSD''
: 'tin' ist etabliert, Linux ist ein UNIX, und diese Gruppe ist die einzige
: mir bekannte, wo derart verstuemmelte Posts auftauchen.
Komisch, genauso mache ich das auch und bis jetzt habe ich keinerlei
Probleme gehabt - ausser dass ueblicherweise die Umlaute auf meinem VT100
nicht so gut aussehen ;-) Ist also m.E. kein Problem der hier verwendeten
Newsreader...
Ciao,
Uwe
--
Dr. Uwe Kreibaum u...@lazlon.mz.rhein-main.de
and...@klemm.gtn.com (Andreas Klemm) schrieb:
> Wenn man erstmal in vi eingearbeitet ist, dann wuenscht man sich keinen
> anderen editor mehr ...
Oh, Andreas, *das* möchte ich nun nicht unterschreiben. Ich kenne
bereits zwei ehemalige bzw. gegenwärtige Kollegen, die mir nach 14
Tagen Emacs gesagt haben: ,,Hmm, ich weiß gar nicht mehr, wie ich das
früher nur mit'm vi alles gemacht habe.'' ;-)
(Einen davon kennst Du auch.)
> Außerdem ist vi _der_ Standard Editor auf allen Unix Platformen ...
ED(1) UNIX Programmer's Manual ED(1)
NAME
ed - text editor
SYNOPSIS
ed [ - ] [ -x ] [ name ]
DESCRIPTION
Ed is the standard text editor.
:-)
(Ich kann mit allen dreien einigermaßen umgehen.)
--
cheers, J"org
joerg_...@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
In article <34884...@news.munich.netsurf.de>, Ro...@majestix.hidden
(root)
writes:
|>Andreas Peters (pe...@math.uni-hamburg.de) wrote:
|>
|>: ja, aber zumindest so wie ich das NIS kenne, kann jetzt jeder an die
|>: NIS-Maps, insbeondere "passwd" kommen. D.h. mein schoenes
|>Shadow-PW-System
|>: nuetzt mir gar nix. Insbesondere, wenn ich verschiedene Unix-Derivate
|>: (AIX 3.25, 4.x -- Solaris 2.5 , 2.6, Linux, HP UX...) habe. Dann
|>kommen
|>: doch glatt noch einige PC-Freaks mit Win95/NT und Chamaelon und
|>aehnlichem.
|>
|>: Das ganze kann auch Aerger machen. Zumal die NFS-Pakete
|>unverschluesselt
|>: uebers Netz wandern, kann man also wunderbar abhorchen.
|>
|>: Wer ansatzweise Loesungen fuer diese Probleme kennt, moege mich bitte
|>: darauf hinweisen.
|>
|>Unter VMS laufen auch alle Pakete unverschluesselt ueber das Netz. Es
|>redu-
|>ziert sich darauf, dass man keine PCs am Netz haben sollte :)
|>
|>Loesungen gegen Password Cracking sind NIS+, Kerberos, oder besser noch
|>Aufklaerung der Anwender.
NIS+ ist SUN-proprietaer und gibt es bisher nicht fuer DEC und SGI.
Fuer Kerberos muss man eine Maschine abstellen, die immer laufen muss. Wer
kann das im Uni-Betrieb gewaehrlisten. Unser RZ sieht sich ausserstande,
zumal denen jetzt massiv das Personal gekuerzt wurde. Die Diskussion ueber
einen Kerberos-Server lief allerdings vor der Kuerzungsmassnahme.
|>
|>Wer physikalischen Zugriff zum Netzwerk erlaubt (PCs), darf sich nicht
|>wundern, dass es Sicherheitsluecken gibt.
Dann muss man a.) den Zugriff via ACL reglementieren bzw.
mitprotokollieren, auch das geht ohne irgendwelche Zusaetze mit
Standard-VMS.
|>
|>Es tun sich da noch ganz andere Luecken auf: Lopez hat sich bei Opel
|>Kisten
|>mit Printouts anfertigen lassen, wie dusselig. Mit einem Laptop koennte
|>so einer jeden Tag einige GigaByte Daten mit nach hause nehmen.
|>
|>Kurzum: es bringt nichts, die eine Schraube 'Password File'
|>festzuziehen,
|>und gleichzeitig den Mitarbeitern Laptops zu verpassen.
|>--
|>-------------------------------------------------------------------------
|>-
|>-
|>-
|>-
|>-
|>-
|>------
|>Ruediger Schuetz Phone/Fax: 00 49-89-65
|>81 92
|>Edlinger Platz 4
|>81543 Muenchen
|>Ruediger...@Munich.Netsurf.DE
|>Germany
|>-------------------------------------------------------------------------
|>-
|>-
|>-
|>-
|>-
|>-
|>------
|>
Eberhard
In article <66aurd$o40$1...@news01.btx.dtag.de>, Manfred...@t-online.de
(Manfred Haertel) writes:
|>Ulli Horlacher schrieb:
|>
|>> (VMS-CLI)
|>> > Pipes sind übrigens kein Vorteil von Unix mehr, in VMS 7.1 sind die
|>> drin
|>> > (inclusive I/O-Redirection mit > und <).
|>>
|>> Falsch. Seit VMS 5.5 (ca 1991).
|>
|>Ja, Du hast recht: In *VMS* sind die schon länger drin, nämlich in der
|>Posix-Shell. Und außerdem gab es Third Party Produkte, die das konnten.
|>
|>In DCL sind sie aber erst seit VMS 7.1.
Die DCL-Pipes sind aber unterste Schublade bezueglich Fahigkeiten.
Dadurch,
dass die Utilities wie z.B. backup auf files schreiben muessen (wg. RMS)
und nicht nach stdout, sprich sys$output, schreiben kann, gehen pipes fuer
Datei bearbeitende Programme nicht:
$ backup/noas sysdisk:/ima/ign=inter | zip "-V" sysdisk.zip sys$input
Das Ding, warum man pipes ueberhaupt braucht, oder?
|>
|>--
|>Manfred Härtel
|>Sprecher der VMS-SIG bei DECUS München e.V.
|>http://www.decus.de
|>
|>
|>
|>
Eberhard
>ED(1) UNIX Programmer's Manual ED(1)
>NAME
> ed - text editor
>SYNOPSIS
> ed [ - ] [ -x ] [ name ]
>DESCRIPTION
> Ed is the standard text editor.
Genau. Da habe ich auch noch was: :-)
When I log into my Xenix system with my 110 baud teletype, both vi
*and* Emacs are just too damn slow. They print useless messages like,
'C-h for help' and '"foo" File is read only'. So I use the editor
that doesn't waste my VALUABLE time.
Ed, man! !man ed
ED(1) UNIX Programmer's Manual ED(1)
NAME
ed - text editor
SYNOPSIS
ed [ - ] [ -x ] [ name ]
DESCRIPTION
Ed is the standard text editor.
- ---
Computer Scientists love ed, not just because it comes first
alphabetically, but because it's the standard. Everyone else loves ed
because it's ED!
"Ed is the standard text editor."
And ed doesn't waste space on my Timex Sinclair. Just look:
- -rwxr-xr-x 1 root 24 Oct 29 1929 /bin/ed
- -rwxr-xr-t 4 root 1310720 Jan 1 1970 /usr/ucb/vi
- -rwxr-xr-x 1 root 5.89824e37 Oct 22 1990 /usr/bin/emacs
Of course, on the system *I* administrate, vi is symlinked to ed.
Emacs has been replaced by a shell script which 1) Generates a syslog
message at level LOG_EMERG; 2) reduces the user's disk quota by 100K;
and 3) RUNS ED!!!!!!
"Ed is the standard text editor."
Let's look at a typical novice's session with the mighty ed:
golem> ed
?
help
?
?
?
quit
?
exit
?
bye
?
hello?
?
eat flaming death
?
^C
?
^C
?
^D
?
- ---
Note the consistent user interface and error reportage. Ed is
generous enough to flag errors, yet prudent enough not to overwhelm
the novice with verbosity.
"Ed is the standard text editor."
Ed, the greatest WYGIWYG editor of all.
ED IS THE TRUE PATH TO NIRVANA! ED HAS BEEN THE CHOICE OF EDUCATED
AND IGNORANT ALIKE FOR CENTURIES! ED WILL NOT CORRUPT YOUR PRECIOUS
BODILY FLUIDS!! ED IS THE STANDARD TEXT EDITOR! ED MAKES THE SUN
SHINE AND THE BIRDS SING AND THE GRASS GREEN!!
When I use an editor, I don't want eight extra KILOBYTES of worthless
help screens and cursor positioning code! I just want an EDitor!!
Not a "viitor". Not a "emacsitor". Those aren't even WORDS!!!! ED!
ED! ED IS THE STANDARD!!!
TEXT EDITOR.
When IBM, in its ever-present omnipotence, needed to base their
"edlin" on a UNIX standard, did they mimic vi? No. Emacs? Surely
you jest. They chose the most karmic editor of all. The standard.
Ed is for those who can *remember* what they are working on. If you
are an idiot, you should use Emacs. If you are an Emacs, you should
not be vi. If you use ED, you are on THE PATH TO REDEMPTION. THE
SO-CALLED "VISUAL" EDITORS HAVE BEEN PLACED HERE BY ED TO TEMPT THE
FAITHLESS. DO NOT GIVE IN!!! THE MIGHTY ED HAS SPOKEN!!!
?
Tschüß,
Michael (emacs Verwender :-)
--
Michael Staats, Theoretical Physics, Uni-GH Duisburg
email: mic...@thp.Uni-Duisburg.DE
<a href="http://WWW.thp.Uni-Duisburg.DE/">Click</a> me!
<a href="http://WWW.thp.Uni-Duisburg.DE/cuaix/cuaix.html">A c.u.aix archive</a>
--
Michael Staats, Theoretical Physics, Uni-GH Duisburg
email: mic...@thp.Uni-Duisburg.DE
<a href="http://WWW.thp.Uni-Duisburg.DE/">Click</a> me!
<a href="http://WWW.thp.Uni-Duisburg.DE/cuaix/cuaix.html">A c.u.aix archive</a>
: > Vorschlag: in UNIX einarbeiten (ja, das ist sperrig, und der vi ist Mist),
: > nach einer Woche ist das groebste geschafft. Dann mit offenen Augen
: > umsehen. Ich wollte heute kein VMS mehr.
: Wenn man erstmal in vi eingearbeitet ist, dann wuenscht man sich keinen
: anderen editor mehr ... wer etwas mehr Komfort moechte, der nimmt vim.
: Außerdem ist vi _der_ Standard Editor auf allen Unix Platformen ...
: Ich frage mich, wie man Server Systeme ohne X11 oder im Netzwerk via
: telnet administrieren moechte, wenn man vi nicht beherrscht ...
: Oder wenn man zum Kunden faehrt ... die haben meistens generische
: Maschinen...
Ich frage mich, warum das hier so seltsam unfreundlich zugeht. Was sollen die
dummen Sprueche? Ich komme klar mit vi, und ich benutze vim. EDV mache ich seit
83 oder so, und UNIX seit 86. Bei Kunden bin ich oft, ich lebe davon.
Was soll solch ein Reply? Willst Du mir zeigen wie doof ich bin? Wie smart
Du bist?
VI ist halt nicht der freundlichste Editor, nicht mehr und nicht weniger habe
ich geschrieben. \(\) usw. kenne und nutze ich seit langer Zeit.
Was wolltest Du schreiben, mein Freund? Wozu soll das gut sein? Koenntest Du
Dir diesen Stil vielleicht einmal abgewoehnen?
Gute Besserung Ruediger
--
------------------------------------------------------------------------------
> When IBM, in its ever-present omnipotence, needed to base their
> "edlin" on a UNIX standard, did they mimic vi? No. Emacs? Surely
> you jest. They chose the most karmic editor of all. The standard.
edlin ist nicht von IBM sondern von Microsoft bzw. daher, wo diese den
Rest vom ersten MS-DOS auch eingekauft haben.
edlin ist kein Klon von Unix ed sondern von CP/M ed.
Frage: was war das Vorbild von CP/M ed?
CP/M soll an alte DEC-Systeme angelehnt sein...
--
Christian "naddy" Weisgerber na...@mips.rhein-neckar.de
See another pointless homepage at <URL:http://home.pages.de/~naddy/>.
Stimmt. Ich verwende daher auch unter VMS den vi. :-)
Mit dem lse obwohl von der Idee her ganz nett konnte ich mich nie
anfreunden weil ohne vt-Tastatur ist der ziemlich krank.
> Genau. Da habe ich auch noch was: :-)
...
> Computer Scientists love ed, not just because it comes first
> alphabetically, but because it's the standard. Everyone else loves ed
> because it's ED!
Ooooch, jetzt hast Du auch noch die Quelle meines Zitats verraten! :-)
Frag ich mich als Unix-Admin ja
1. Wie man ein NT administrieren kann
und
2. Warum hat M$ mit NT ein OS abgeliefert das nicht
mal multiuser-tauglich ist - dabei waren da VMS-
Entwickler dabei.
Die erwaehnten VMS-Entwickler sind evident Vollidioten
Peter
"An NT box can be run by an idiot.... and usually is"
Vorschlag: der Midnight Commander hat einen WIRKLICH guten integrierten
editor
(nicht diese Emacs-clones joe jemacs und wie sie immer heissen moegen).
> Ich frage mich, warum das hier so seltsam unfreundlich zugeht. Was sollen die
> dummen Sprueche? Ich komme klar mit vi, und ich benutze vim. EDV mache ich seit
> 83 oder so, und UNIX seit 86. Bei Kunden bin ich oft, ich lebe davon.
Ha! vi ist ein Toilettenreiniger. Emacs steht fuer Escape Meta Alt
Control Shift.
Soviel zu relioesen fragen...
<evil grin>
Peter
--
wolfgang
--
#include <disclaimer.h>
... vi stuff ...
[ snipped ]
Worum geht's hier eigentlich? Der vi wuerde keinen Ergonomie Preis gewinnen,
jawoll, ich benutze vim. Ist vi damit erledigt? :)
Fuer alle TECO Fans: ich habe noch ein Original Manual im Schrank, aus PDP
Zeiten. Hartgesottenen fertige ich gegen Kostenerstattung eine Kopie davon
an. Irgendwer soll es uebrigens mal geschafft haben, mit TECO Macros die
Zahl PI bis auf einige Hundert Stellen zu berechnen. Weiss nicht ob das
stimmt, aber es gibt definitiv noch etwas Schlimmeres als den vi :)
Zur urspruenglichen Frage zurueck: der Unterschied zwischen UNIX und VMS ist,
dass ich fuer VMS staendig zahlen muesste, und fuer UNIX zahle ich wenig oder
gar nichts (Linux). Auf der Suche nach VMS Software laufe ich mir die Hacken
wund, und fuer UNIX bekomme ich allererstklassigste Software gaenzlich kosten-
los. Mehr als ein Mensch in einem Leben ausprobieren kann, for free.
Ich war frueher selber einmal ein VMS Fanatiker, und habe UNIX gehasst. Linux
hat mich versoehnt, und auf meinem Desk steht auch eine 255/233 mit DEC UNIX.
UNIX hat auch von VMS gelernt, siehe ksh93, sowie endlich einmal 1/2 gescheites
Error Reporting.
VMS ist proprietaer und leider tot, UNIX ist erwachsen geworden, und Win NT
ist ein vorlautes Etwas, das noch viel lernen muss. So sehe ich das.
Allen gegen UNIX voreingenommenen sei hiermit noch einmal allerwaermstens
LINUX empfohlen. Der vim kann Cut and Paste "mit Einfaerben" wie der EDT,
die BASH kann Command Line Completion (VMS Abkuerzungen, ca.), und die Man
Pages haben mittlerweile durchaus die Qualitaet von VMS Help Files.
Ein extrem schickes UNIX gibt es von DEC, nur kostet das leider, und doof,
wie die Company ist, vermarktet sie es nicht passend.
Gruss Ruediger
Und ich dachte, das steht fuer "Eight Megabytes And Continuously Swapping" :-)
(auch wenn diese Interpretation in Zeiten von Alphas mit 8GB RAM an
Bedeutung verloren hat - sollte man ihn in EGACS umbenennen?!)
: Soviel zu relioesen fragen...
: <evil grin>
Um noch etwas Oel in das Flame-Feuer "vi gegen den Rest der Welt" zu
giessen: den EDT gibt's auch fuer andere Plattformen... Aber der ist
bestimmt nicht kryptisch genug fuer Unixoide...
Insgesamt ziehe ich aber auch Editoren vor, die nicht WYSIWYG sind,
sondern die der Philosophie "You asked for it, now you've got it"
folgen. Sie bieten einfach - wenn man sich einmal eingearbeitet hat -
Vorteile in der Bedienbarkeit.
cu,
Martin
--
| Martin Vorlaender | VMS & WNT programmer
Ceterum censeo | work: m...@pdv-systeme.de
Redmondem delendam esse. | http://www.pdv-systeme.de/users/martinv/
| home: mar...@radiogaga.harz.de
> 2. Warum hat M$ mit NT ein OS abgeliefert das nicht
> mal multiuser-tauglich ist - dabei waren da VMS-
> Entwickler dabei.
>
> Die erwaehnten VMS-Entwickler sind evident Vollidioten
Die Entwickler ganz sicher nicht, der NT-Kernel ist nämlich schon
wunderschön (siehe "Inside Windows NT").
Ich frage mich nur immer, warum so viele schöne Features des Kernels dem
Programmierer verborgen bleiben...
Ja, frag ich mich manchmal auch.
> und
>
> 2. Warum hat M$ mit NT ein OS abgeliefert das nicht
> mal multiuser-tauglich ist - dabei waren da VMS-
> Entwickler dabei.
>
Das liegt wohl eher daran, dass WNT nach "oben" genauso
chaotisch aussehen musste wie das alte Windows ... oder
so aehnlich. Das ist jedenfalls meine Vermutung.
Von aussen erinnert Windows NT jedenfalls viel mehr an
Windows 3.1/95 als an VMS. Und "von aussen" sieht man
auch die aergerlichen Eigenschaften (z.B. bzgl.
Systemverwaltung oder die Sache mit der Mehrbenutzerfaehigkeit).
Ueber den Kernel kann ich nicht viel sagen, aber es gibt Leute,
die sich besser auskennen, die behaupten, der sei gar nicht soo
schlecht.
Apropos Systemverwaltung: Ich hab einen Kollegen, der verwaltet
ein PC-Netz. Er hat auch zwei WNT-Systeme, von denen er behauptet,
die koenne man schon irgendwie sicher machen, aber da das
wohl ziemlich schwierig ist, laesst er lieber keine Benutzer drauf.
Dann hab ich Kollegen, die muessen Unix-System verwalten (HP-UX)
und aergern sich damit rum, aber immerhin laufen die meistens
so einigermassen (die Systeme, aber die Verwalter manchmal auch ;-)).
Nur soll (bzw. kann) man z.B. keine erweiterten ACLs benutzen ...
die gibt's angeblich in der naechsten Betriebssystemversion
sowieso nicht mehr. Naja, das ist halt der Fortschritt.
Wo gibt's den? Wuerde mich interessieren.
Naja, es gibt Software bei DECUS, aber es stimmt schon: Hat man keine
besonderen
Anforderungen, z.B. zu Hause oder im kleinen Buero, und keine
Campuslizenz
(die ist gut), dann sind die Kosten das Hauptargument gegen VMS. Bei
professionellen Anwendungen mit hoher Verfuegbarkeit und teurem
Servicevertrag
sieht das aber sicher ganz anders aus. Ist wohl auch ein
Marketingproblem (s.u.).
>
> Ich war frueher selber einmal ein VMS Fanatiker, und habe UNIX gehasst. Linux
> hat mich versoehnt, und auf meinem Desk steht auch eine 255/233 mit DEC UNIX.
> UNIX hat auch von VMS gelernt, siehe ksh93, sowie endlich einmal 1/2 gescheites
> Error Reporting.
Linux wird sicher noch viele Freunde gewinnen, denn 1. hat man auf dem
PC nicht so viele preiswerte Alternativen, zweitens kostet's (fast)
nichts,
3. gibt's wirklich viel Software. Aber auf vielen Kisten laeuft Linux ja
nicht mit vielen Benutzern. Wenn man mich vor die Wahl stellen
wuerde, Systemverwalter einer Unix- oder einer VMS-Kiste mit z.B. 500
oder 5000 Benutzern zu sein, wuerde ich VMS vorziehen - das ist die
andere
Seite. Dabei bin ich weder ein VMS-"Fanatiker" noch ein Unix-"Hasser".
Ich kann mir aber gut vorstellen, auf einem privaten PC mit Linux
zu arbeiten. Aber da bin ich alleiniger Benutzer und Verwalter.
>
> VMS ist proprietaer und leider tot, UNIX ist erwachsen geworden, und Win NT
> ist ein vorlautes Etwas, das noch viel lernen muss. So sehe ich das.
Nun ja, manches an Unix ist auch proprietaer (hier war schon die Rede
vom DLM
von Sun, von AFS usw.) Aber das Portieren von Anwendungen faellt
zwischen
verschiedenen Unix-Versionen dennoch leichter. Andererseits gibt's Posix
fuer VMS. WNT ist natuerlich ebenso proprietaer wie Windows 3.1 oder 95.
Und ob VMS tot ist, entscheidet sich vermutlich --- am Marketing.
> Allen gegen UNIX voreingenommenen sei hiermit noch einmal allerwaermstens
> LINUX empfohlen. Der vim kann Cut and Paste "mit Einfaerben" wie der EDT,
> die BASH kann Command Line Completion (VMS Abkuerzungen, ca.), und die Man
> Pages haben mittlerweile durchaus die Qualitaet von VMS Help Files.
Haben die inzwischen auch so eine hierarchische Struktur? Nun ja, ich
glaube
heutzutage koennte man ohnehin das Hilfesystem in HTML (nur Text!) zur
Verfuegung stellen und sowas wie Lynx dazu, waer vielleicht am besten.
Dann haette man Links in den Hilfetexten, und das Format der Dateien
waere standardisiert.
>
> Ein extrem schickes UNIX gibt es von DEC, nur kostet das leider, und doof,
> wie die Company ist, vermarktet sie es nicht passend.
Das Marketingproblem ist bei VMS eher noch groesser. Und unterm Strich
spielen Preis- und Lizenzpolitik (hat nicht die grosszuegige
Lizenzvergabe
Unix gross gemacht?) eine groessere Rolle als die technischen
Eigenschaften,
solange nur gewisse Mindestanforderungen erfuellt werden. Und natuerlich
das Softwareangebot, aber das ist ja auch oft eine Folge des Marketings.
> Auf der Suche nach VMS Software laufe ich mir die Hacken
> wund,
Schon mal bei DECUS nachgefragt? ;-)
> VMS ist proprietaer und leider tot
Vorurteil. VMS ist immer noch überall dort zu finden, wo es *wirklich*
auf Verfügbarkeit ankommt und somit ganz und gar nicht tot. Wenn auch
nicht mehr so sehr im Rampenlicht wie vor 10,15 Jahren.
enjoy
delta
--
helmut springer Consulting Unix, IP, Security, InfoServices
de...@RUS.Uni-Stuttgart.DE Stuttgart University, FRG
http://home.pages.de/~delta/
phone : +49 711 685-2003 "Freedom's just another word for
FAX : +49 711 685-7096 nothing left to lose" Kris Kristofferson
Das wuerde die W95 Leute abschrecken und am Ende kaeme noch jemand auf die
Idee etwas anderes als W95 auf den Kernel draufzusetzen.
DEC plant angeblich aus VMS und NT fuer ihre Alphas "ein Ding" zu machen
sowie Digital Unix einzustellen. Wer Unix will nimmt dann Linux.
F'up
: Nun ja, manches an Unix ist auch proprietaer (hier war schon die Rede
: vom DLM
: von Sun, von AFS usw.) Aber das Portieren von Anwendungen faellt
: zwischen
: verschiedenen Unix-Versionen dennoch leichter. Andererseits gibt's Posix
: fuer VMS. WNT ist natuerlich ebenso proprietaer wie Windows 3.1 oder 95.
Hat jemand damit Erfahrungen gemacht?
Bin gerade dabei, eine Applikation zu entwickeln und sie musz
sowohl auf VMS als auch auf Unix laufen ...
Ist zB der gcc auf VMS brauchbar? Gibt es auf VMS Libraries, so dasz
ich ganz normale Unix Funktionaliaeten verwenden kann ohne mir
eine eigene "wrapper" library schreiben zu muessen um auf der
einen Seite mit RMS auszukommen und auf der anderen Seite mit
Un*x filesystemen? Oder tut das die Posix library?
Gibt es ein Handbuch von Dec bezueglich Portierung zwischen den
zwei Welten und was man VMS seitig beachten musz?
Any experience welcome...
cu,
Leon Aaron Kaplan
Stimmt sogar. Mein Kollege benutzt ihn unter DEC OSF1 auf einer Alpha.
Das einzige Problem dabei ist, dass man zum gewohnten Arbeiten auch eine
entsprechende Tastatur braucht. Deshalb sitzt mein Kollege vor 2 seriellen
Terminals mit DEC Tastatur und einer normalen Workstation fuer graphische
Anwendungen.
Wenn man genug Platz auf dem Schreibtisch hat ...
so long
MUFTI
--
Eine Unter-Speisekarte wird erscheinen, in der Sie waehlen koennen,
entweder zu spielen, oder das Video zu schlingen.
(aus einem Software-Handbuch, Stichworte: menu und loop)
Stimmt weil man mit OpenNT ein vollwertiges Unix draufsetzen kann 8-)
>Ich frage mich nur immer, warum so viele schöne Features des Kernels dem
>Programmierer verborgen bleiben...
Weil die meisten Programmierer den NT-Kernel nicht mit OpenNT Unix benutzen 8-)
Hmm komisch. Ich kenne gar keinen Unix-Editor (auf die schnelle fallen
mir da 7 Stueck != vi ein), der im Textmodus betrieben wird und F-Tasten
verlangt.
Welcher Unixeditor im Textmodus arbeitet denn mit F-Tasten ?
ACL's kann man unter fast Unix mit dem AFS-Filesystem machen, das fuer fast
alle halbwegs wichtigen Unixe portiert wurde.
In Zukunft wird vermutet, dass sich die Weiterentwicklung von AFS,
das DFS-Filesystem durchsetzen wird.
> Welcher Unixeditor im Textmodus arbeitet denn mit F-Tasten ?
Alle UNIX-Editoren mit EDT Modus - wenn du das numerische Keypad mit den
PF-Tasten als F-Tasten ansiehst. Davon fallen mir spontan 6 Stueck ein.
--
\ Ulli 'Framstag' Horlacher \ BelWue-Koordination \ fram...@belwue.de \
\ Universitaet Stuttgart \ Allmandring 30 \ D-70550 Stuttgart \ Germany \
\ SAFT://saft.belwue.de/framstag \ HTTP://www.belwue.de/ \
\ "X.500: Security through Complexity" - Juergen G. \
> Ist zB der gcc auf VMS brauchbar?
Leider keine Erfahrung. Unter VMS gibt es den gcc aber auch nur für VAX,
*nicht* für Alpha! Eine Einbenutzer-Lizenz für DEC-C, den C-Compiler für
Digital kostet jedoch auch nicht die Welt.
> Gibt es auf VMS Libraries, so dasz
> ich ganz normale Unix Funktionaliaeten verwenden kann ohne mir
> eine eigene "wrapper" library schreiben zu muessen um auf der
> einen Seite mit RMS auszukommen und auf der anderen Seite mit
> Un*x filesystemen? Oder tut das die Posix library?
Zum einen kannst Du Dein Programm unter dem Posix Subsystem laufen
lassen, aber auch wenn Du ein "normales" VMS-Programm schreibst, stehen
Dir (fast) alle Run-Time-Library-Funktionen zur Verfügung, die es auch
unter Unix gibt. Du *mußt* nicht auf RMS-Ebene runtergehen.
> Gibt es ein Handbuch von Dec bezueglich Portierung zwischen den
> zwei Welten und was man VMS seitig beachten musz?
Da gab's meine ich mal was, kann mich aber nicht mehr an den Titel
entsinnen. Am besten mal bei DEC nachfragen. Oder mal eine Anfrage auf
DECUSnet starten, ob das da einer kennt...
In article <66o708$g8d$1...@news00.btx.dtag.de>, Manfred...@t-online.de
(Manfred Haertel) writes:
|>Leon Kaplan schrieb:
|>
|>> Ist zB der gcc auf VMS brauchbar?
|>
|>Leider keine Erfahrung. Unter VMS gibt es den gcc aber auch nur für VAX,
|>*nicht* für Alpha! Eine Einbenutzer-Lizenz für DEC-C, den C-Compiler für
|>Digital kostet jedoch auch nicht die Welt.
|>
|>> Gibt es auf VMS Libraries, so dasz
|>> ich ganz normale Unix Funktionaliaeten verwenden kann ohne mir
|>> eine eigene "wrapper" library schreiben zu muessen um auf der
|>> einen Seite mit RMS auszukommen und auf der anderen Seite mit
|>> Un*x filesystemen? Oder tut das die Posix library?
|>
|>Zum einen kannst Du Dein Programm unter dem Posix Subsystem laufen
|>lassen, aber auch wenn Du ein "normales" VMS-Programm schreibst, stehen
|>Dir (fast) alle Run-Time-Library-Funktionen zur Verfügung, die es auch
|>unter Unix gibt. Du *mußt* nicht auf RMS-Ebene runtergehen.
|>
|>> Gibt es ein Handbuch von Dec bezueglich Portierung zwischen den
|>> zwei Welten und was man VMS seitig beachten musz?
1.) Es gibt ein Buch "Interoperability: OpenVMS and DEC OSF/1
Interoperability Guide"
EC-N3399-43, das als ps-file im www erhaeltlich war und vielleicht noch
ist.
Wenn es nicht mehr aufliegt, koennte ich mal in meinen Muellbergen
suchen...
2.) Vieles ist verfuegbar, es kommt natuerlich auf den code drauf an. In
der Regel hilft es,
den code unveraendert zu compilieren und zu binden, um zu sehen, was
wirklich
unix-spezifisch ist.
|>
|>Da gab's meine ich mal was, kann mich aber nicht mehr an den Titel
|>entsinnen. Am besten mal bei DEC nachfragen. Oder mal eine Anfrage auf
|>DECUSnet starten, ob das da einer kennt...
|>
|>--
|>Manfred Härtel
|>Sprecher der VMS-SIG bei DECUS München e.V.
|>http://www.decus.de
|>
|>
|>
Eberhard
Ich habs probiert und nicht fuer administrierbar befunden.
> > und
> >
> > 2. Warum hat M$ mit NT ein OS abgeliefert das nicht
> > mal multiuser-tauglich ist - dabei waren da VMS-
> > Entwickler dabei.
> >
>
> Das liegt wohl eher daran, dass WNT nach "oben" genauso
> chaotisch aussehen musste wie das alte Windows ... oder
> so aehnlich. Das ist jedenfalls meine Vermutung.
Schon moeglich, das deswegen so muell wie \ statt / erklaert
werden kann. Aber es erklaert nicht warum VMS programmierer
die _wirklich_ wissen was ein multiuser-system ist WNT
als single-user krueppel auf die welt brachten... Oder
bin ich schon eine Ebene zu weit oben?
> Von aussen erinnert Windows NT jedenfalls viel mehr an
> Windows 3.1/95 als an VMS. Und "von aussen" sieht man
> auch die aergerlichen Eigenschaften (z.B. bzgl.
> Systemverwaltung oder die Sache mit der Mehrbenutzerfaehigkeit).
click-click-click - please reboot -
Ab mehr als 3-4 Benutzer kann man NT rauchen. Egal ob die
nun gleichzeitig drauf sind oder ob man bloss die accounts
administrieren muss (NT administrieren? da geh ich lieber
Bagger fahren oder Kran steuern - ist interessanter).
> Ueber den Kernel kann ich nicht viel sagen, aber es gibt Leute,
> die sich besser auskennen, die behaupten, der sei gar nicht soo
> schlecht.
>
> Apropos Systemverwaltung: Ich hab einen Kollegen, der verwaltet
> ein PC-Netz. Er hat auch zwei WNT-Systeme, von denen er behauptet,
> die koenne man schon irgendwie sicher machen, aber da das
> wohl ziemlich schwierig ist, laesst er lieber keine Benutzer drauf.
> Dann hab ich Kollegen, die muessen Unix-System verwalten (HP-UX)
> und aergern sich damit rum, aber immerhin laufen die meistens
> so einigermassen (die Systeme, aber die Verwalter manchmal auch ;-)).
> Nur soll (bzw. kann) man z.B. keine erweiterten ACLs benutzen ...
> die gibt's angeblich in der naechsten Betriebssystemversion
> sowieso nicht mehr. Naja, das ist halt der Fortschritt.
Ich weiss.
Mac - du denkst es laeuft, aber es laeuft nicht
Windows - du denkst es lauft nicht, und es laeuft nicht
Unix - du denkst es laeuft nicht, aber es laeuft.
Ueber VMS kann ich nix gross sagen - man weiss eben dass sie
toll clustern und ..ehm... fuerchterliche syntax haben.
Was Unix betrifft: ich staune ja auch immer wieder ;)
Das gibt es schon. Unter FreeBSD finde ich in /usr/share/doc eine
ganze Menge an Dokumentation in HTML. Lynx kommt eh' mit dem System
mit und Apache als Webserver ist auch da. Auf www.freebsd.org kann
man auch über eine Suchmaschine auf die Manualpages zugreifen. Ob
letzteres ins Standardsystem integriert ist/wird, weiß ich aber nicht.
Gruß,
Ripley
--
http://www.in-berlin.de/User/nostromo/
>> Welcher Unixeditor im Textmodus arbeitet denn mit F-Tasten ?
> ich denke da z. B. an emacs, ... [über die anderen kann ich nicht
> urteilen]
Huh? Ich hätte mich vermutlich nie mit dem Emacs anfreunden können,
wenn ich auf sowas wie F-Tasten _angewiesen_ wäre. Ich mag meine
Finger normalerweise nämlich auch nicht vom Hackbrett wegnehmen, egal
ob zur F-Tastenreihe oder zu einer Maus.
Mittlerweile haben bei mir die F-Tasten unter Emacs in der Tat ein
paar Funktionen bekommen, das ist aber nichts, was man nicht 1.) durch
M-x <something> nicht auch erreichen könnte, und 2.) nichts, was ich
während eines Editiervorganges in irgendeiner Form häufig aufrufen
müßte. Stattdessen sind es so Sachen wie `gdb', `grep' oder
`compile'. Auch `goto-line' ist dabei, wobei ich da nicht verstehe,
warum RMS das nicht auf was einfacheres gelegt hat.
> Ich weiss.
> Mac - du denkst es laeuft, aber es laeuft nicht
> Windows - du denkst es lauft nicht, und es laeuft nicht
> Unix - du denkst es laeuft nicht, aber es laeuft.
VMS - du denkst, es läuft und es läuft.
War das einzige, was noch offen war ;-) , aber es trifft wirklich zu!
--
Georg Wagner
-----------------------------------------------------------------
Union Bank of Switzerland / Schweizerische Bankgesellschaft
j.> so Sachen wie `gdb', `grep' oder `compile'. Auch `goto-line'
j.> ist dabei, wobei ich da nicht verstehe, warum RMS das nicht
j.> auf was einfacheres gelegt hat.
Bei mir schon lange auf C-c g
Aber gewundert habe ich mich auch schon immer.
Cheers
Axel
--
Axel Stegner Uni: +64-9-373 7599 x6808
Computer Science Department Fax: +64-9-308 2377
Division of Science & Technology
University of Auckland - Tamaki Campus, Auckland, New Zealand
> VMS - du denkst, es läuft und es läuft.
Unix - Du denkst, es laeuft und es laeuft besser, als Du gedacht hast.
:-)
--
Stefan Stapelberg Fon: +49-9352-89948 RENT-A-GURU (TM)
<ste...@rent-a-guru.de> Fax: +49-9352-89949 P.O. Box 1358
<ste...@sgi.de> http://www.netstore.de/ D-97803 Lohr/Main
Gute Idee, sind zwar drei Tasten, aber man muß die Hand nicht kilometerweit
bewegen, wie bei F4... (-:
--
Olav "Mac" Wölfelschneider wo...@rbg.informatik.th-darmstadt.de
PGP fingerprint = 06 5F 66 B3 2A AD 7D 2D B7 19 67 3C 95 A7 9D AF
But let your communication be Yea, yea; nay, nay: -- Matthew 5:37
for whatsoever is more than these cometh of evil. on computers
Meinst du DCL? Ich denke wenn man es gewohnt ist ist es sogar besser
als die typische Unix-Bedienung. zB ist es voellig unlogisch dass
zum Anzeigen der Zeit "date" verwendet wird und zum setzen erst
recht. Unter VMS:
show time
set time
Alles ganz logisch. Ungewohnt fuer Leute die Unix kennen sicher auch
fuer mich.
Nun muss ich auch noch meinen Senf dazu tun. DCL ist ja nicht nur auf
VMS, sondern auch auf RSX-11M und sogar RT11 zu haben gewesen. Der
Befehl, nur Dateien mit aktuellem Datum zu kopieren, lautete
jeweils:
$ COPY/SINCE (VMS)
COPY/TODAY (RSX-11M)
COPY/NEW (RT-11)
Soviel zur Logik.
--
Dipl.-Math. Wilhelm Bernhard Kloke
Institut fuer Arbeitsphysiologie an der Universitaet Dortmund
Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 montags und dienstags
[...]
> $ COPY/SINCE (VMS)
Das Kommando heisst ja eigentlich
$ COPY/SINCE=TODAY
was doch schon sehr an
> COPY/TODAY (RSX-11M)
erinnert. Dass die Option TODAY als Standard weggelassen werden kann,
ist sicher nicht als Nachteil zu bezeichnen.
> COPY/NEW (RT-11)
Davon abgesehen ist fuer mich (kenne beide Systeme aus Administrator-
und Nutzersicht seit ca. 10 Jahren) die Antwort nach dem "besseren"
Betriebssystem klar. Ebenso klar ist mir jedoch, dass wohl noch nie
ein Unix-Freak von den zahlreichen Vorteilen von VMS fuer Einsteiger,
Programmierer und Systemmanager ueberzeugt wurde (orthogonale an
englische Sprache angelehnte Kommandostruktur, einheitliches Message-
Handling, hierarchisches Hilfesystem, homogenes ueberschaubares Sy-
stem, VAXCluster mit zentralen Massenspeichern via HSC, einheitliche
Tools und Bibliotheken fuer alle Programmiersprachen, leistungsfaehi-
ges Dateisystem und Recordmanagement, Dateiinstallation zur Lastver-
ringerung, volle Kompatibilitaet ueber weite Hardware- und VMS-Rel-
ease-Bereiche, fruehzeitiges SMP, Abkuerzbarkeit der Komandos,
Logicals, grosser Teil der Systemfunktionen steht auch auf DCL-
Niveau zur Verfuegung, Zentralisierung der Nutzer- und Systemver-
waltung auf wenige Tools und Rechner, umfangreiche Moeglichkeiten
zur Gewaehrleistung der Systemintegritaet wie ca. 40 Privilegien,
nutzerbezogene Quoten fuer alle Systemressourcen, ACLs auch fuer
Queues und Devices, Loginflags ...).
--
Kay-Uwe Loebel
Technische Universitaet Chemnitz
mailto:loe...@e-technik.tu-chemnitz.de
http://www.infotech.tu-chemnitz.de/~bauel/loebel.html
> Nun muss ich auch noch meinen Senf dazu tun. DCL ist ja nicht nur auf
> VMS, sondern auch auf RSX-11M und sogar RT11 zu haben gewesen. Der
> Befehl, nur Dateien mit aktuellem Datum zu kopieren, lautete
> jeweils:
> $ COPY/SINCE (VMS)
> COPY/TODAY (RSX-11M)
> COPY/NEW (RT-11)
>
> Soviel zur Logik.
> --
> Dipl.-Math. Wilhelm Bernhard Kloke
> Institut fuer Arbeitsphysiologie an der Universitaet Dortmund
> Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 montags und dienstags
Moment einmal,
der richtige Befehl bei VMS lautet:
COPY/SINCE=TODAY
Und DCL auf RSX, naja... So ganz DCL war das ja nicht, oder ?!
Aber ich stelle wieder mal fest, dass die Diskussion sich
ausschliesslich um die Commandlineparser dreht und nicht um das
Betriebssystem. Die aber sind austauschbar, wie man ja an der Vielzahl
von Shells fuer UNIX sieht. Bei VMS halt es halt keiner noetig, andere
Syntax zu benutzen. Man ist zufrieden ;-)
Also, wie waere es denn mit der Diskussion:
Vor-/Nachteile des Schalenmodells bei VMS oder Kernel-message-system
versus Shared-memory ?
Mathias
> Also, wie waere es denn mit der Diskussion:
> Vor-/Nachteile des Schalenmodells bei VMS oder Kernel-message-system
> versus Shared-memory ?
Oder: Plattformuebergreifende Portabilitaet und Hersteller-
Unabhaengigkeit, das waere IMHO der Punkt, ueber den die
Unix-Fans zu begeistern waeren ... Aber wem sage ich das,
schliesslich ist ja Digital nach eigener Darstellung die
Firma, "which invented Unix". ROTFL :-)
SCNR,
Stefan
> Bei mir schon lange auf C-c g
Hmm, ich hätte nicht gedacht, daß eine der gut erreichbaren Tasten-
kombinationen in der Tat noch frei ist. ;-) Den merk' ich mir...
<off topic>
Oh, .nz, Ihr habt gerade Sommer... Hier wird's im Moment so richtig
kalt.
</off topic>
von orthogonal kann keine Rede sein, s.o.
>Handling, hierarchisches Hilfesystem, homogenes ueberschaubares Sy-
>stem, VAXCluster mit zentralen Massenspeichern via HSC, einheitliche
>Tools und Bibliotheken fuer alle Programmiersprachen, leistungsfaehi-
>ges Dateisystem und Recordmanagement, Dateiinstallation zur Lastver-
Gerade das Dateisystem ist IMHO kein Vorteil von VMS. Es ist
langsam, inflexibel ( z.B. max. 8 Ebenen, bzw. ueber die Kruecke der
rootet file systems 16, was man dann wieder beim Backup buesst). Nein,
nein nein.
>ringerung, volle Kompatibilitaet ueber weite Hardware- und VMS-Rel-
>ease-Bereiche, fruehzeitiges SMP, Abkuerzbarkeit der Komandos,
>Logicals, grosser Teil der Systemfunktionen steht auch auf DCL-
Praktisch alle Unix-Ssytemfunktionen stehen auf Shell-Ebene zur
Verf"ugung.
>Niveau zur Verfuegung, Zentralisierung der Nutzer- und Systemver-
>waltung auf wenige Tools und Rechner, umfangreiche Moeglichkeiten
>zur Gewaehrleistung der Systemintegritaet wie ca. 40 Privilegien,
Aber da man nie weiss, welche Privilegien man wirklich braucht, gibt man
sich am besten alle.
>nutzerbezogene Quoten fuer alle Systemressourcen, ACLs auch fuer
>Queues und Devices, Loginflags ...).
Das waere auch Eulen nach Athen tragen.
Wer ein genuegend brauchbares Tool in der Hand haelt, der wird den Teufel tun
und noch mal ganz von vorne anfangen fuer die paar Vorteile, die ihm ein
Umstieg bringt (von den zahlreichen Nachteilen mal abgesehen).
Aus aehnlichen Gruenden laueft bei mir zu Hause Linux und nicht FreeBSD.
BTW: ich kenne einen Unix-Freak, der immer noch an die Vorteile von
VMS glaubt 8-)
so long
MUFTI
--
Legen Sie die Hochspannungsleitung ueber die Tastatur und
benutzen sie die Machtentfaltung.
(Installationsanleitung IBM Xterminal,Stichworte: 220V-Kabel und Power Supply)
> Peter Keel <pk...@cyberlink.NOSPAM.ch> wrote:
> > Ueber VMS kann ich nix gross sagen - man weiss eben dass sie
> > toll clustern und ..ehm... fuerchterliche syntax haben.
>
> Meinst du DCL? Ich denke wenn man es gewohnt ist ist es sogar besser
> als die typische Unix-Bedienung. zB ist es voellig unlogisch dass
> zum Anzeigen der Zeit "date" verwendet wird und zum setzen erst
> recht. Unter VMS:
> show time
> set time
Ja, dieses und das "HELP"-Kommando werden immer wieder als
Beispiele fuer die vorbildliche Kommando-Syntax von VMS zitiert.
Wie aber erklaere ich einem VMS-Neuling, dass er zum Wechseln
eines Directories nicht etwa "cd foo", sondern so etwas wie
SET DEFAULT [.FOO]
eintippen muss, wobei der Punkt und die Klammern essentiell
wichtig sind, und man einen Tippfehler erst beim naechsten
Kommando mitbekommt. Ist das gut?
Oder was ist der Unterschied zwischen einem Symbol und einem
Logical, und wann brauche ich was... (bitte jetzt nicht _mir_
erklaeren)
Und warum muss man staendig diese 6 Nullen tippen:
DIR DISK:[000000.MYDIR]
Wenn es 5 Nullen oder 7 oder garkeine sind, kriegt man Fehlermeldungen.
Albern, nicht?
Gruss,
Christian
--
----------------------------------------------------------------------------
Dipl.-Inform. Christian Knapmeyer Email: kna...@tecmath.de
TECMATH GmbH Voice: 06301/606-0 Fax: 06301/606-67
Sauerwiesen 2 Face : Room 249
67661 Kaiserslautern, Germany Disclaimer: as usual
---------- press any key to continue. press any other key to quit.----------
[...]
> Und warum muss man staendig diese 6 Nullen tippen:
> DIR DISK:[000000.MYDIR]
> Wenn es 5 Nullen oder 7 oder garkeine sind, kriegt man
> Fehlermeldungen. Albern, nicht?
Keineswegs, denn in Deinem Beispiel kannst Du die Nullen (und
den Punkt) weglassen. Sie muessen nur geschrieben werden, wenn
Du auf das Root-Directory zugreifen willst.
>[...]
>Das Kommando an sich verdeutlicht sehr schoen die an die eng-
>lische Sprache angelehnte Befehlsstruktur:
>SET: Kommando (auch SHOW, ...)
>DEFAULT: Objekt (auch TIME, FILE, UIC, PRIV, SYMBOL, ...)
>[.FOO]: Parameter
Wenn das Kommando was mit der englischen Sprache zu tun haette,
dann muesste es das Wort "DIRECTORY" in irgend einer Form enthalten.
DEFAULT kann nun alles moegliche bedeuten.
Vielleicht heisst das Kommando ja aber auch SET DEFAULT$DIRECTORY oder
so aehnlich und SET DEFAULT ist nur ein gebraeuchliche Abkuerzung.
Eine sinnenstellende Abkuerzung macht aber auch nicht gerade eine
gute Befehlssyntax, beim "cd" kann man sich wenigstens noch die Bedeutung
merken (waehrend ich SET DEFAULT schon wieder vergessen habe, obwohl ich
frueher einige Zeit auf VMS gearbeitet habe).
so long
MUFTI
--
exited
An die Anwendung kann nicht angehaengt werden.
NT Fehlercode 87.
(aus einer Programmfehlermeldung)
> Aber da man nie weiss, welche Privilegien man wirklich braucht, gibt man
> sich am besten alle.
??? Wer macht denn sowas. Ist doch ganz klar: Der gewoehnliche Benutzer
bekommt
per Default zwei Privileges, die man ihm nur in Ausnahmefaellen nimmt.
Muss
einer eine einzelne Queue verwalten (Start/Stop, Jobs loeschen oder
Startzeit
aendern usw.), gibt man ihm dort das Zugriffsrecht. Soll er generell
Operator-
Taetigkeiten uebernehmen, kriegt er OPER Privilege usw. Soll er z.B.
Prozesse
seiner eigenen Gruppe abschiessen koennen, bekommt er GROUP Privilege.
Naja,
der Systemverwalter kriegt alle, das ist bei Unix auch so. Aber
natuerlich
kann der sich vor allzuviel Leichtsinn auch schuetzen, da er ja zwischen
authorized und default Privs unterscheiden kann und nicht jedem seiner
Prozesse alle Privs geben muss.
Dass man einem Benutzer einfach alle Privileges gibt, weil man nicht
weiss, welche er braucht, kann ich mir eigentlich nicht vorstellen.
Ich finde die Privileges jedenfalls praktisch - aber wie bereits
frueher gesagt: Ich will niemandem die Freude an seinem Unix nehmen.
Klar, unter Unix gibt's halt keine logischen Namen, deshalb muss
man's einem Unix-Freak erst erklaeren. Ist immer so, wenn man
von einem Betriebssystem kommt und ein anderes kennenlernen will
- oder?
>
> Und warum muss man staendig diese 6 Nullen tippen:
> DIR DISK:[000000.MYDIR]
> Wenn es 5 Nullen oder 7 oder garkeine sind, kriegt man Fehlermeldungen.
> Albern, nicht?
Ja, ziemlich albern, denn ich wuerde halt einfach DIR DISK:[MYDIR]
eintippen. Ich glaube jedes Betriebssytem sieht ziemlich albern aus,
wenn man sich anstrengt, es moeglichst unsinnig zu bedienen.
Ich glaube auch, dass bei den Betriebssystemen viel Gewohnheitssache
ist. Bei der Oberflaeche sowieso, die ist ja austauschbar.
Das Problem ist doch: Wenn man nicht mit beiden Systemen wirklich
arbeitet, kennt man halt nur das eine gut ... siehe oben:
DIR DISK:[000000.MYDIR]
Trotzdem: das Unix-Aequivalent zu
search [mydir...]x*.tex /exclude=xa* /modif/since=yesterday wort
ist, glaube ich, ziemlich kompliziert ...
Ach ja, das Kommando sucht in allen Directories ab [mydir] abwaerts
in allen Datein x*.tex (erklaert sich selber, oder?), ausser xa*,
die seit gestern geaendert wurden, nach dem Wort "wort".
Aber ich bin mir sicher, dass Ihr mir ein Beispiel bringt, das
unter Unix ganz einfach - wenn auch nicht so selbsterklaerend -
geht, deshalb wuerde ich den Kommandointerpreter nicht ueberbewerten,
schliesslich kann man DCL ja auch auf Unix draufsetzen (und
umgekehrt z.B. Posix-Shell auf VMS).
Und neuerdings wollen die Kids sowieso nur noch die Maus
umherschubsen und ab und zu mal klicken. Die bewundern Leute,
die noch mit der Kommandozeile arbeiten koennen, wie die
Fossilien im Museum ...
Nein, denn eigentlich beinhaltet es nicht nur die aber
man kann den Rest weglassen (z.B. Knoten oder Device), wenn man
nur die Directory, wechselt.
> Vielleicht heisst das Kommando ja aber auch SET DEFAULT$DIRECTORY oder
> so aehnlich und SET DEFAULT ist nur ein gebraeuchliche Abkuerzung.
> Eine sinnenstellende Abkuerzung macht aber auch nicht gerade eine
> gute Befehlssyntax, beim "cd" kann man sich wenigstens noch die Bedeutung
> merken (waehrend ich SET DEFAULT schon wieder vergessen habe, obwohl ich
> frueher einige Zeit auf VMS gearbeitet habe).
Klar, arbeitest ja noch mit Unix, oder?
Aber eigentlich sind das Details, die sowohl unter Unix als auch unter
VMS notfalls nach Geschmack anzupassen sind. Wenn's sonst keine Probleme
gibt ...
Eben: Das ist doch in aller Regel entscheidend: Das eine System kenne
ich,
ich kann auch alles oder fast alles, was ich brauche, irgendwie
hinkriegen,
also spar ich mir die Muehe, mich in was anderes einzuarbeiten. Spielt
meiner Meinung nach in 99% eine viel groessere Rolle als alles andere.
Schon um ein Betriebssystem beurteilen zu koennen, muss man sich
doch ziemlich lang damit befassen - oder?