|
AW: SMBv1 Windows XP
Zitat:
Noch gar nicht lang her, da habe ich eine 45 Jahre alte Simatic S3 nach jahrelangem Todeskampf in die ewigen Schaltkreise ziehen lassen müssen. Die Maschine war gar nicht mal kompliziert. Mangels 1:1-Ersatz kam ein, man halte sich mal fest, Raspberry Pi zum Einsatz. Steuerungssoftware für Sensoren und Aktoren war in einer Woche selbst geschrieben mit Lazarus. Materialkosten plus Arbeitszeit knapp 2000 Euro. Retrospektiv flossen in die Lebenserhaltung der S3 in den 5 Jahren zuvor knapp 96.000 Euro. Als das mal fertig war wurde es lustig: Plötzlich konnte man die Maschine nach eigenen Bedürfnissen anpassen, was vorher mangels Quellcode der EPROM-Daten nicht ging. Bessere Integration in den Betriebsablauf sparte dann 5000 Euro pro Woche. (Das nur mal als kleine Exkursion in die Praxis) |
AW: SMBv1 Windows XP
Respekt an sich.
Das Abwägen Kosten/Nutzen geht bspw. im Falle von medizinischen Geräten selten bis gar nicht auf. Es wird einmal investiert und dann ist Geld da und sonst nicht. Das führt egal ob in öffentl. Händen oder privaten im Rahmen der Budgetierung zu Arschleiden bei den Betroffenen. Der Hersteller seinerseits verkauft ein 'neues' Gerät mit 'neuem' Windows oder hat Linux bspw. im Einsatz. Es wird nicht ein neuer PC beigestellt, sondern der Hersteller will eine neue 'Maschine' verkaufen. Ein Freund von mir hat im Allgemeinen Krankenhaus mal in den Archiven, dort wo dich die Mumien grüßen, einen Treiber gefunden und Hieroglyphen entziffert bis was einst in einem PC Sarkophag eingebettet war den Ausgang fand und heute eine virtuelle Box beseelt. Die Abwägung von Opportunitäten ist oft nicht die Stärke von budgetierenden Organisationen. 'Hauptsache WIR haben *alle* Arbeit' - weißt eh wie es ist :-D. Wenn alles andere liegen bleibt, dann haben in 20 Jahren auch noch was zu tun. Nachteil. Wenn man in 20 Jahren macht was vor 10 Jahren hätte fertig sein sollen. An sich noch eine Anmerkung zum WebDAV von zuvor. Bei mir (nicht unter XP, solch einen Rechner habe ich gar nicht mehr) läuft ein WsgiDAV (höchste 2.xer Version). Kennt jemand einen nicht Java basierten, abseits von im Apache usw.. integrierte Alternative? Zitat:
|
AW: SMBv1 Windows XP
Zusammenfassend kann man doch sagen: Das Problem der veraltenden Software wird man immer wieder haben. Das der entscheidenden IT-Laien auch. Wir Nerds können die Firma nicht retten, wenn wir zwar auf dem Mac-Guyver-Lehrgang waren, aber kein Budget für Kaugummis und Büroklammern vorhanden ist. Denn der Aufbau von Kleinserien-Produktionsstraßen für Kaugummis und Büroklammern kostet auch ;-)
(Am Rande bemerkt war es genau diese Art Probleme, die mich dann den Arbeitgeber wechseln ließ) |
AW: SMBv1 Windows XP
Unter Windows hat es sich eingebürgert viel Logik die dort nix zu suchen hat in die Anwendung reinzuziehen. Auf dem Weg fällt der Aufwand den eigentlich der Sysadmin hätte auf den Programmier zurück :-D. Auf dem Weg hat das MS ECO System in den 90ern die Arbeit ins niedrigere Preisniveau verschoben. An sich zwar korrekt, da nur eine Ressource den Teil implementiert, aber unflexibel Ende nie. Wenn man alle unnotwendig integrierten Abhängigkeiten aus einem Programm eliminiert, dann bedarf es kaum mehr eines Updates.
Auf dem Weg über FTP wird eigentlich sauberer entkoppelt. Anwendung und File sind so konzipiert, dass die Anwendung einfach eine File liest und schreibt. Mehr leistet die Kombination nicht. Deswegen wird eine File transferiert resp. eigentlich kopiert. Eine Anwendung darf über die Verteilung von Files nichts wissen. Dafür ist die Anwendung nicht zuständig. Das Filesystem selbst ist nicht der perfekte Ort an dem eine Verteilung von Files soll und kann konfiguriert werden. Die File Schnittstelle zum konkreten Betriebssystem unterliegt an sich mal kaum Veränderungen und muss da sich das OS selbst drauf verlässt eher sehr stabil sein. Die zweite Kombi ist ein Protokoll und eine Netzwerkkommunikation im LAN mittlerweile. An sich ist die Idee ein File zu transferieren eine gute. Diese Vorgang zu entkoppeln mittels FTP Programm macht schon Sinn und eine bessere. EAI und zentrale Datenhaltung bieten Lösung aber nicht immer zum Problem passend. Das Verteilen von Files ist eigentlich unpassend. Business getriebene IT Organisationen kennen Files und Datenbanken und von letzteren bestenfalls Entity Relationship. ER ist nichts anderes als ein Minimalkonsens der verbreitet wurde. UML ditto. Im ersten Fall wollten die Unternehmen den Usern das Strukturwissen über die Informationsmodelle abluchsen und im zweiten vom Entwicklerteam. Win 3.5 NT hatte nach der DEC VAX genauso wie OS/2 einen funktionierenden Real-Time 'Mechanismus', welcher sich mit NT 4.x langsam von selbst erledigte. (große Industrieanlagen) Damit kam der PC in manche technisch angestammte Bereiche und gesellte sich zur MS-DOS Intel Assembler Kombination hinzu welche in der Systemautomatisierung verbreitet wurde. Auf magische Art und Weise konnte auf dem Weg der Durchsatz einer Maschine erhöht werden (Produktion in kleineren Betrieben). Die Integration hat man in der Produktion. Auf Siemens ist/war beinahe exklusiv über lange Zeiträume dahingehend Verlass, dass die Analgen liefen und Teile lange hielten. Erst durch die Standardisierung im E.U. Raum haben die Mitbewerber müssen mitziehen. Aus der Welt kommen diese Lösungen für Messageräte. Die kennen ewige Wahrheiten und Files sind eine davon. Dazu gesellt sich noch die Diskussion um herstellergetriebene vs. offene Standards. MS-LAN Manger war ein illusterer Versuch für kleine Netzwerke. Technisch skalieren die zwar heute weitaus mehr, aber die Art der Umsetzung ist noch immer die Definition der 'Verteilung' im Filesystem. Für alles andere braucht man Infrastruktur. Die UNIX hatten ja mal den Zugang, welcher auch in einem OS reflektiert ist, alles ist ein File und rest wird unter der Haube gemacht. Der nächste Wahnsinn ist das Pushing der Files oder unnotwendige Information über die Bereitstellung die eher der Synchronität des Arbeitsprozesses des Users geschuldet ist. Dafür könnte man sich auch im Filesystem von der Änderung einer Datei informieren lassen, sofern die Anwendung läuft. Das ist der Punkt. Aus Sicht der Anwendung ist der Weg natürlich und komfortabel. In der Praxis folgt aber die Vorgehensweise dem Florianiprinzip. Windows hat sich von der IBM Welt einfach nicht ganz emanzipieren können und genauso wie SAP IBM hörige IT Organisation in ihre Welt transferiert. Die Leute kennen mehr oder weniger, wenn überhaupt wie zuvor ... Linux schafft die Verbindung von der technischen Welt mit der kaufmännischen, btw. eine komplett absurde auf historischem Ballast gewachsene Trennung die es eigentlich nicht mehr geben sollte, so lala, aber schon komfortabel (FTP Verbindung auf eine Verzeichnis mounten). Auf ein gemapptes Laufwerk zu schreiben ist im Moment beinahe sicherer als auf einen Datenträger. So ändern sich die Zeiten. An sich wäre die saubere Lösung für einen Push tatsächlich mal der Message Broker. Der MB ist nichts anderes als die vollautomatisierte Variante einer Branche in den U.S. Die Unternehmen haben ursprünglich Files konvertiert. Zitat:
|
AW: SMBv1 Windows XP
Zitat:
Und darf ich Dich mal daran erinnern was Dein Job ist? Ich will Lösungen, keine Probleme. :evil: Gruß K.H |
AW: SMBv1 Windows XP
Zitat:
|
AW: SMBv1 Windows XP
Zitat:
|
AW: SMBv1 Windows XP
Zitat:
|
AW: SMBv1 Windows XP
Zitat:
So hätte es sein müssen: Zitat:
|
AW: SMBv1 Windows XP
Zitat:
|
| Alle Zeitangaben in WEZ +1. Es ist jetzt 01:01 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz