http://visualstudiomagazine.com/columns ... alsid=2469
Speciellt referensen till "the best operating system ever invented" i andra stycket...
Intressant artikel om programmeringsspråk
"the .NET platform is language neutral"
".NET is just the VB runtime all grown up and made language neutral"
"latest iteration of the language wars: VB vs. C#", vs Java - C++ - Lisp - Python etc..
"There were no such wars on OpenVMS" - Högst trovärdigt.
"FORTRAN was far better at solving mathematical problems than other languages,"
"I hear that F# is particularly good at solving mathematical problems"
Ett nytt fall av http://en.wikipedia.org/wiki/Embrace, extend and extinguish
"He is a Microsoft Regional Director, MVP and INETA speaker. Rockford is the
Principal Technology Evangelist for Magenic, a Microsoft Gold Certified Partner."
Kommentar#1:
"due to the Architecture of the Calling Standard. The mechanism used to pass
parameters and control to and from a routine is the same for all compilers," (på OpenVMS).
".NET has incompatible competitors (alternate calling mechanisms and object
file formats) on the operating system, there will be weakness in every
connection", mao MS-Win lär fortsatt vara en inkompabilitets djungel.
Kommentar#2:
"Business programmers given the choice between VB and Java generally took
that later.", så valet är inte mellan C#/VB utan mellan C# - VB - C++ - Java etc..
".NET is just the VB runtime all grown up and made language neutral"
"latest iteration of the language wars: VB vs. C#", vs Java - C++ - Lisp - Python etc..
"There were no such wars on OpenVMS" - Högst trovärdigt.
"FORTRAN was far better at solving mathematical problems than other languages,"
"I hear that F# is particularly good at solving mathematical problems"
Ett nytt fall av http://en.wikipedia.org/wiki/Embrace, extend and extinguish
"He is a Microsoft Regional Director, MVP and INETA speaker. Rockford is the
Principal Technology Evangelist for Magenic, a Microsoft Gold Certified Partner."
Kommentar#1:
"due to the Architecture of the Calling Standard. The mechanism used to pass
parameters and control to and from a routine is the same for all compilers," (på OpenVMS).
".NET has incompatible competitors (alternate calling mechanisms and object
file formats) on the operating system, there will be weakness in every
connection", mao MS-Win lär fortsatt vara en inkompabilitets djungel.
Kommentar#2:
"Business programmers given the choice between VB and Java generally took
that later.", så valet är inte mellan C#/VB utan mellan C# - VB - C++ - Java etc..
-
MicaelKarlsson
- Inlägg: 4669
- Blev medlem: 18 juni 2004, 09:16:07
- Ort: Aneby
- Kontakt:
Samma API rakt över alla språk är helt klart intressant. Något att köra i halsen på nästa M$ säljare. "Jag vill ha OpenVMS, det är bättre än M$ enligt er själva" 
Kan man uppgradera själva "kernel" i OpenVMS under drift?
Alternativt skulle man kunna spara ner alla applikationer som en coredump ung som "dvala" (hibernation) på moderna laptop. Uppgradera OS, ladda in systemminnet från disk. Och fortsätta som inget har hänt. Samma uptid etc..
Kan man uppgradera själva "kernel" i OpenVMS under drift?
Alternativt skulle man kunna spara ner alla applikationer som en coredump ung som "dvala" (hibernation) på moderna laptop. Uppgradera OS, ladda in systemminnet från disk. Och fortsätta som inget har hänt. Samma uptid etc..
> Samma API rakt över alla språk är helt klart intressant.
Jag vet inte riktigt vad du menar med "API" här, men det som avses
i artikeln är "Calling standard". D.v.s t.ex att då man i C anropar en funktion
(en egen i applikationen eller en systemfunktion, det är samma sak) så
kan den funktionen vara skrivet i valfritt annat språk, från MACRO (d.v.s
assembler) till valfritt 3G språk.
> Kan man uppgradera själva "kernel" i OpenVMS under drift?
Om man har krav på OS-uppgradering under drift så klustrar man
två (eller fler, upp till 96 maskiner stöds) "burkar" och uppgraderar
en i taget. Standardrutin och har fungerat sedan VMS-Clusters kom
ca 1983-84. Man tar alltså ner en maskin i taget och uppgraderar den
(kan vara antingen OS-upgrade eller helt ny hårdvara). Efter omboot
tar man nästa maskin när det passar, det behöver inte ske samtidigt.
Effekten blir att det inte blir något avbrott för användarna.
Jag vet inte riktigt vad du menar med "API" här, men det som avses
i artikeln är "Calling standard". D.v.s t.ex att då man i C anropar en funktion
(en egen i applikationen eller en systemfunktion, det är samma sak) så
kan den funktionen vara skrivet i valfritt annat språk, från MACRO (d.v.s
assembler) till valfritt 3G språk.
> Kan man uppgradera själva "kernel" i OpenVMS under drift?
Om man har krav på OS-uppgradering under drift så klustrar man
två (eller fler, upp till 96 maskiner stöds) "burkar" och uppgraderar
en i taget. Standardrutin och har fungerat sedan VMS-Clusters kom
ca 1983-84. Man tar alltså ner en maskin i taget och uppgraderar den
(kan vara antingen OS-upgrade eller helt ny hårdvara). Efter omboot
tar man nästa maskin när det passar, det behöver inte ske samtidigt.
Effekten blir att det inte blir något avbrott för användarna.
Calling standard brukar väl även definera hur variabler lämnas över till anropade rutiner, och av urklippet att dömma så var det också det som poängterades.
När man en gång i tiden gjorde DLL:er för VB6 var man tvungen att definera exporterade funktioner som __stdcall för att VB skulle kunna hantera dom.
Men mest lurad blev jag av att OpenVMS inte körde en microkernel som ju kan uppgraderas helt utan omstart.
När man en gång i tiden gjorde DLL:er för VB6 var man tvungen att definera exporterade funktioner som __stdcall för att VB skulle kunna hantera dom.
Men mest lurad blev jag av att OpenVMS inte körde en microkernel som ju kan uppgraderas helt utan omstart.
Är inte just microkernel lite överhoppad filosofi idag - vacker i teorin men ingen har lyckats riktigt bra med implemeteringen i verkligheten - NT4 var väl hyffsat renodlad microkernel medans man gick ifrån det mer och med iom. win2k, XP mm. av just prestandaskäl, framför allt på grafiksidan för support av spel mm..
läste för länge sedan en närmast berömd 'gräl' mellan Linus och Tannenbaum just angående microkernelfolosofin vs. monolitkärnan Linux (även om den nu är moduluppdelad med dynamisk laddning efter behov) och kan i prinsip översättas med gräl mellan akademisk 'snygghet' och 'principer' gentemot att få något att fungera i verkligheten med lite prestanda...
läste för länge sedan en närmast berömd 'gräl' mellan Linus och Tannenbaum just angående microkernelfolosofin vs. monolitkärnan Linux (även om den nu är moduluppdelad med dynamisk laddning efter behov) och kan i prinsip översättas med gräl mellan akademisk 'snygghet' och 'principer' gentemot att få något att fungera i verkligheten med lite prestanda...
> Calling standard brukar väl även definera hur variabler lämnas över till anropade rutiner,
Exakt. Och det är det som är standardiserat i OpenVMS över alla kompilatorer.
> Men mest lurad blev jag...
Av vem ?
> Hur hanterar den maskinen som skall tas ner dom applikationer som körs ..?
Men kan göra det på lite olika sätt.
Om det gäller rena serverapplikationer (databaser o.s.v) så kan man "stänga"
en maskinen för nya anslutningar, sedan vänta på att de befintliga loggar
av. När det gäller interaktiva användare så är det samma sak, man stänger
maskinen för nya inloggningar. Sedan när allt har lugnat ner sig så är det
bara att ta ner systemet. All last ligger då på de andra maskinena i klustret.
När maskinen sedan botas in i klustret igen så kommer lasten att fördelas
över alla maskinerna igen.
Om man har en applikation som bara körs på *en* maskin (finns ingen
anledning), så får man göra lite extra åtgärder. Men som sagt, om man inte
gör något väldigt speciellt så är alla applikationer "cluster-aware" per default.
Allting i klustret är delat mellan maskinerna. D.v.s diskar, printköer,
batchköer, "lock manager" o.s.v. För t.ex en databas så körs databas
processor på alla maskiner mot samma diskar (och databas) samtidigt.
Alla accesser sker direkt från alla processer, ingen dedikerad "DB-writer"
som ligger på en viss maskin. Om en maskin kraschar så tar övriga
maskiner hand om rollback av eventuella öppna transaktioner. O.s.v.
Exakt. Och det är det som är standardiserat i OpenVMS över alla kompilatorer.
> Men mest lurad blev jag...
Av vem ?
> Hur hanterar den maskinen som skall tas ner dom applikationer som körs ..?
Men kan göra det på lite olika sätt.
Om det gäller rena serverapplikationer (databaser o.s.v) så kan man "stänga"
en maskinen för nya anslutningar, sedan vänta på att de befintliga loggar
av. När det gäller interaktiva användare så är det samma sak, man stänger
maskinen för nya inloggningar. Sedan när allt har lugnat ner sig så är det
bara att ta ner systemet. All last ligger då på de andra maskinena i klustret.
När maskinen sedan botas in i klustret igen så kommer lasten att fördelas
över alla maskinerna igen.
Om man har en applikation som bara körs på *en* maskin (finns ingen
anledning), så får man göra lite extra åtgärder. Men som sagt, om man inte
gör något väldigt speciellt så är alla applikationer "cluster-aware" per default.
Allting i klustret är delat mellan maskinerna. D.v.s diskar, printköer,
batchköer, "lock manager" o.s.v. För t.ex en databas så körs databas
processor på alla maskiner mot samma diskar (och databas) samtidigt.
Alla accesser sker direkt från alla processer, ingen dedikerad "DB-writer"
som ligger på en viss maskin. Om en maskin kraschar så tar övriga
maskiner hand om rollback av eventuella öppna transaktioner. O.s.v.
En monotlitisk kärna borde ju rimligtvis vara mest optimalt om man är ute efter snabbhet och respons, och om jag inte missminner mig är Linus rätt inriktad på att få Linux på skrivbordet och då kan man ju förstå att det är att föredra.
OpenVMS verkar däremot ha en hel del implementerat som ändå drar ner hastigheten i form av minnesaccesskontroll och allt sodjan "pladdrat" i.
Trodde det var givet med en microkernel i det läget och noll downtime...
OpenVMS verkar däremot ha en hel del implementerat som ändå drar ner hastigheten i form av minnesaccesskontroll och allt sodjan "pladdrat" i.
Trodde det var givet med en microkernel i det läget och noll downtime...
Det är naturligtsvis totalresultatet som är intressant !
Om användarna upplever 100% uptime så är det ju totalt ointressant
om en alla annan *individuell* CPU har varit nere någon gång. Om
detta dessutom alltid sker planerat och under kontroll, så är det
ju endå bättre. Snabbhet och respons är av noll värde om man inte
dessutom har alla andra bitar på plats.
Och, som sagt, det är ju alltid totalbilden man måste studera. Alla OS har
sina svagheter, OpenVMS har t.ex ett filsystem som kan upplevas som
"långsamt", men å andra sidan så har jag aldrig varit med om att en
oplanerad krasch någonsin har givit ett korrupt filsystem. Det lär hända
på andra OS, vad jag har hört, alltså...
Om användarna upplever 100% uptime så är det ju totalt ointressant
om en alla annan *individuell* CPU har varit nere någon gång. Om
detta dessutom alltid sker planerat och under kontroll, så är det
ju endå bättre. Snabbhet och respons är av noll värde om man inte
dessutom har alla andra bitar på plats.
Och, som sagt, det är ju alltid totalbilden man måste studera. Alla OS har
sina svagheter, OpenVMS har t.ex ett filsystem som kan upplevas som
"långsamt", men å andra sidan så har jag aldrig varit med om att en
oplanerad krasch någonsin har givit ett korrupt filsystem. Det lär hända
på andra OS, vad jag har hört, alltså...
