Reliant Unix; SystemV standard auf mips portieren auf Debian system unter Qemu
HerrBrand
Also gut, das ganze Projekt handelt um folgendes:
Ein Kunde hat ein ERP System, welches unter X.BASIC geschrieben wurde
auf einem IBM Reliant Linux läuft . Dieses ist nach dem SystemV Unix
Standard aufgebaut und läuft auf einem mips Kernel.
Diese Hardware wird aber von IBM nicht mehr weiter supported.
Diese ERP Software ist im Laufe der Jahre gewchasen und es steckt eben
eine Menge KnowHow darin, so das der Kunde unbedingt dieses System
weiterhin behalten will.
Das naheliegenste war das ganze auf ein Solaris System zu portieren,
doch Solaris gibt es eben nicht mit mips für welches das X.BASIC
compiliert wurde.
Neu Compilieren könne wir die Software nicht, da die Quelldateien vom
X:Basic nicht vorhanden sind. Das ist damals von IBM mitgeliefert
worden und wurde speziell auf die Harware kompiliert.
Als Lösungsansatz scheint mit hier der Weg zu passen das ganze unter
Qemu laufen zu lassen, denn dafür gibt es ein mips-kernelimage für
Debian.
Soweit so gut.
Zum laufen haben wir es ja schon bekommen, das X.BASIC auf mips
emulation-system.
UNd nu kommt mein Problem. Die einzelnen ERP Module wurde unter diesen
System geschrieben und sind als *.pkg vorhanden. Damit kann ich aber
unter Debian nichts anfagen.
Wie bekomm ich denn nun die *.pkg in *.deb umgewandelt.
Mit alien geht es nur in die andere Richtung
Der versuch des umwandeln bringt die Fehlermeldung, das die pkginfo
fehlt.
Meine googlerecherchen haben gezeigt, das ich hier ein passendes
Packet brauchen würde: sunwpkgcmdsu. Die hab ich auch als anscheinend
Quelldatei gefunden, welches auch ein Debian ordner enthält. Aber ich
finde keine readme Datei die mir sagen würde wie ich das packet
compilieren kann.
Also steht ich da ich armer Thor, und bin so Klug als wiezuvor!
So fühle ich mich nun.
Übrigens, Gespräche mit Fujitsu Siemens haben ergeben, as die das wenn
überhaupt nur auf Solaris mit Sparc portieren wollen. Wobei die dann
aber das gelcieh Probelm hätten. Als ich sie darauf ansprach wurde
ihre Aussagen doch wieder etwas vorsichtiger.
KAnn mir da nun vielleicht jemand helfen?
Weiß da jemand vielelciht Rat?
Joerg Scheurich aka MUFTI
> doch Solaris gibt es eben nicht mit mips für welches das X.BASIC
> compiliert wurde.
Ein anderes verbreitetes Linux-mips-System ist die Sony Playstation 2.
Die Hardware ist nicht allzu schnell und nicht besonders stabil, waere
aber vielleicht einen Versuch wert.
AFAIK laeuft auch der Rechner in einem Plastik-Pinguin unter Linux auf
einer mips Architektur, das ist allerdings auch nicht der Renner 8-(
Andere Linux-mips-Hardware ist von SGI. Da gibt es wirklich grosse Kisten
allerdings muss man sehr genau hinschauen, was unter Linux laeuft und was
nicht.
Allerdings ist auch die SGI mips Architektur inzwischen ausgelaufen.
Aktuelle Hardware unter Linux mips gibt es AFAIK als Entwicklungssystem
(z.B. um damit Routersoftware oder aehnliches zu entwickeln).
> Meine googlerecherchen haben gezeigt, das ich hier ein passendes
> Packet brauchen würde: sunwpkgcmdsu. Die hab ich auch als anscheinend
> Quelldatei gefunden, welches auch ein Debian ordner enthält. Aber ich
> finde keine readme Datei die mir sagen würde wie ich das packet
> compilieren kann.
Quellverzeichnisse mit Debian-Patches uebersetzt man ueblicherweise mit so
was wie
$ dpkg-buildpackage -us -uc -rfakeroot
dann faellt am Ende ein normales .deb-Packet und fast ein halbes Dutzend
debian spezifische Dateien raus.
so long
MUFTI
--
Einzelne Beiträge waren mit dem grafischen Signet eines lachenden
Gesichts versehen.
Bayerischer Verwaltungsgerichtshof 3.6 2002, AZ: 7 CS 02.875, Stichwort: 8-)
HerrBrand
> Quellverzeichnisse mit Debian-Patches uebersetzt man ueblicherweise mit so
> was wie
>
> $ dpkg-buildpackage -us -uc -rfakeroot
>
> dann faellt am Ende ein normales .deb-Packet und fast ein halbes Dutzend
> debian spezifische Dateien raus.
NUn das zählt für den Fall, das es ein solches Quellpaket ist. Aber
das knn ich nicht erkennen.
Mich verwirrtt eben der Ordner mit den Debian details und ich weiß
nicht was sich damit anfangen soll.
Ich wollte ja auch mit "alien" nicht das quellpaket umwandeln, sondern
die vorhandenen *.pkg der ERP Software. Wenn ich das hinbekommen
könnte aus den pkg eben deb zu machen, dann könnte ich es mit der
Lösung Debian-mips Kernel auf qemu laufen lassen.
Das wäre schon mla ein guter Anfang
Florian Weimer
> Also gut, das ganze Projekt handelt um folgendes:
> Ein Kunde hat ein ERP System, welches unter X.BASIC geschrieben wurde
> auf einem IBM Reliant Linux läuft . Dieses ist nach dem SystemV Unix
> Standard aufgebaut und läuft auf einem mips Kernel.
> Diese Hardware wird aber von IBM nicht mehr weiter supported.
Und Siemens? Das stammt schließlich von denen. Wenn IBM das Euch
verkauft hat, dann nur im Rahmen eines Wartungsvertrages.
> Neu Compilieren könne wir die Software nicht, da die Quelldateien vom
> X:Basic nicht vorhanden sind. Das ist damals von IBM mitgeliefert
> worden und wurde speziell auf die Harware kompiliert.
Das dürfte auch mit Quellen ein ziemliches Abenteuer sein.
> Als Lösungsansatz scheint mit hier der Weg zu passen das ganze unter
> Qemu laufen zu lassen, denn dafür gibt es ein mips-kernelimage für
> Debian.
Das ist aber eine ziemlich andere Architektur.
> Zum laufen haben wir es ja schon bekommen, das X.BASIC auf mips
> emulation-system.
Wirklich? Wow.
> Der versuch des umwandeln bringt die Fehlermeldung, das die pkginfo
> fehlt.
Das gibt's auf jedem SVR4-System, z.B. auch unter Solaris.
> finde keine readme Datei die mir sagen würde wie ich das packet
> compilieren kann.
Dieses Nexenta-Paket enthält gar keine Quellen. Entweder findest Du sie
in OpenSolaris -- oder Du mußt die Konvertierung unter einem vorhandenen
SVR4-System machen.
HerrBrand
> * HerrBrand:
>
> Und Siemens? Das stammt schließlich von denen. Wenn IBM das Euch
> verkauft hat, dann nur im Rahmen eines Wartungsvertrages.
Auf Solaris kann man das porteiren. Aber bei genauerem Nachfragen wie
das gehen soll, da es ja kein mips mehr gibtkommen sie ins schleudern
was ihre Argumentation betrifft. Das Probelm an der Sacheist, das man
das X.Basic als quelle braucht. Das gibts abver anscheinend nirgends
mehr. UNd as ist auch das Problem von FSc
. Denn die haben da ja damals von "SiemensNixdorf" gekauft und "nur"
supported" . Anscheinend haben oder finden die das slebst nicht mehr.
Sie könnten zwar ne Lösung bieten, doch die wird dann so teuer, das
man auch gleich ein neues ERp schrieben lassen kann und es auf
"normalen" Seven betreiben kann. Diese Lösung ist auch angedacht,
sofern sich ncihts anders finden läßt.
>
> Das dürfte auch mit Quellen ein ziemliches Abenteuer sein.
Das denke ich nicht. Hätte wir das würde es gehen.
wir haben uns mal zu testzecken Surfbasic besorgt, das kommt sehr nahe
an X.Basic ran und das lief einwandfrei unter Solaris. Aber dann müßte
man auch da die ganze ERp Software dann darauf anpassen. Doch das
problem bei dieser Sache ist einfach die, das es für das SurfBasic so
ungefähr noch 2 quellen gibt, die das auch erstmal rauskramen mußten.
Die wollen ne Menge Kohle für das ding aber wollen keien Suopport
bieten. Nun gut den würden wir ja noch machen wenn wir den Quellcode
bekämen, doch den wollen sie nicht rausrücken. das ist dann doch etwas
heikel.
>
> Das ist aber eine ziemlich andere Architektur.
>
Da gebe ich dir recht, es ist eine ander Architektur. Aber wie schon
erwähnt, habeen wir das X.Basic da zum laufen gebracht. Doch nu stehen
wir eben vor dem Problem, das die ganzen ERP Pakete eben *.pkg sind.
Also kann debian damit nichts anfangen.
> > Zum laufen haben wir es ja schon bekommen, das X.BASIC auf mips
> > emulation-system.
>
> Wirklich? Wow.
>
Ja, ist ne heiden Arbeit gewesen, aber es geht ;-)
> > Der versuch des umwandeln bringt die Fehlermeldung, das die pkginfo
> > fehlt.
>
> Das gibt's auf jedem SVR4-System, z.B. auch unter Solaris.
>
> > finde keine readme Datei die mir sagen würde wie ich das packet
> > compilieren kann.
>
> Dieses Nexenta-Paket enthält gar keine Quellen. Entweder findest Du sie
> in OpenSolaris -- oder Du mußt die Konvertierung unter einem vorhandenen
> SVR4-System machen.
Mmmmh, das Probelm was ich aber habe ist doch, das die INfos die dann
darin stehennicht mit dem Debiansystem übereinstimmen., oder seh ich
das falsch?
Bernd Eckenfels
> Sie könnten zwar ne Lösung bieten, doch die wird dann so teuer, das
> man auch gleich ein neues ERp schrieben lassen kann und es auf
> "normalen" Seven betreiben kann. Diese Lösung ist auch angedacht,
> sofern sich ncihts anders finden läßt.
> Da gebe ich dir recht, es ist eine ander Architektur. Aber wie schon
> erwähnt, habeen wir das X.Basic da zum laufen gebracht. Doch nu stehen
> wir eben vor dem Problem, das die ganzen ERP Pakete eben *.pkg sind.
> Also kann debian damit nichts anfangen.
Aber das ist doch kein Problem, einfach auspacken (auf solaris) und
rueberkopieren. Da braucht es doch nicht mal debian pakete (wozu, ist doch
eh legacy)
> Mmmmh, das Probelm was ich aber habe ist doch, das die INfos die dann
> darin stehennicht mit dem Debiansystem übereinstimmen., oder seh ich
> das falsch?
Wozu brauchst du die? Einfach in ein Verzeichnis packen und ausführen.
Gruss
Bernd
Dietrich Schaffer
[...]
Riecht nach Comet Top für x.basic ;-)
Müßte mal nachschauen, was ich noch so habe...
Sollte obiges zutreffen, wurde dann noch mit LIGA gearbeitet?
Servus,
Dietrich
HerrBrand
> HerrBrand <i...@brand-saarbruecken.de> wrote:
>
> [...]
>
> Riecht nach Comet Top für x.basic ;-)
>
> Müßte mal nachschauen, was ich noch so habe...
> Sollte obiges zutreffen, wurde dann noch mit LIGA gearbeitet?
>
SCO wäre schon mal ein Anfang.
Wir haben das X.Basic soweit am laufen, das wir es ausführen können
und solche "Fehlermeldungen" erhalten wie das der X.BASIC Uswr fehlt.
Und das ist nun unser Problem. wir müßten über dieses
"Fehlermeldungsverfahren alles Dateein rausfinden die wir noch
brauchen und dann kopieren.
Aber dann stehen wir schon vor dem nächsten Problem. Wo müssen denn
die Dateien auf den emulierten Debian-mips System hinkopiert werden?
Aus deisem Grunde wäre es sehr viel einfacher eben einfach das
Quellpaket für X.BASIC zu haben.
Dann würde das andere auch funktionieren.
pkg unter Solrais entpacken und einfach kopieren.
HerrBrand
Jo, LIGA. Und das X.Basic würde wir für INtel brauchen. Aber SCO wäre
auch schon sehr gut.
X.BASIC "läuft" soweit, das wir die Dateien ausführen können, die dann
"richtige" Fehlermeldungen bringen, die darauf verweisen, das uns zB
der X.BASIC User fehlt. hat man das dann erledigt komt die nächst
eDateifehlermeldung usw.
Das liegt daran, das wir alles benötigeten Dateien und Lib kopieren
müßten, aber das st ne heiden Arbeit.
Dietrich Schaffer
[...]
Bin am Montag wieder in der Firma und werde nachschauen, was da noch
so ist. ( u. U. Sourcen für Mips )
Servus,
Dietrich
Dennis Grevenstein
>
> Ein anderes verbreitetes Linux-mips-System ist die Sony Playstation 2.
> Die Hardware ist nicht allzu schnell und nicht besonders stabil, waere
> aber vielleicht einen Versuch wert.
Ist das Ding nicht MIPSel?
> Andere Linux-mips-Hardware ist von SGI. Da gibt es wirklich grosse Kisten
> allerdings muss man sehr genau hinschauen, was unter Linux laeuft und was
> nicht.
> Allerdings ist auch die SGI mips Architektur inzwischen ausgelaufen.
Bis zur Origin 2000 gibt es Linux fuer die Kisten.
Aber dann koennte man wohl direkt eine grosse RM nehmen und das
Reliant UNIX behalten.
> Aktuelle Hardware unter Linux mips gibt es AFAIK als Entwicklungssystem
> (z.B. um damit Routersoftware oder aehnliches zu entwickeln).
Das scheint doch vielversprechender. Von Broadcom gibt es sowas.
http://www.linux-mips.org/wiki/Systems
gruss,
Dennis
--
Don't suffer from insanity...
Enjoy every minute of it.
HerrBrand
>Bis zur Origin 2000 gibt es Linux fuer die Kisten.
> Aber dann koennte man wohl direkt eine grosse RM nehmen und das
> Reliant UNIX behalten.
So ists. Das wäre ja dann die "letzte" Lösung und teuer dafür was zu
erhalten was es nicht mehr "gibt" Allerdings wird das , wenn es keine
andere Lösung gibt angestrebt um eine Notlösung für den Ausfall zu
haben um eine ERP für neue HArdware zu schreiben.
> > Aktuelle Hardware unter Linux mips gibt es AFAIK als Entwicklungssystem
> > (z.B. um damit Routersoftware oder aehnliches zu entwickeln).
>
> Das scheint doch vielversprechender. Von Broadcom gibt es sowas.http://www.linux-mips.org/wiki/Systems
Nun ja, mein Probelm liegt darin, das di momentan das ganze als
Terminal Server haben, und da werd ich wohl mit den Umgebungen nicht
viel hinbekommen oder nur serh sehr schwer wenn ich sehe was die an
Hardware unterstützen.
@Dietrich
DAs wäre echt klassse von dir. Ich hoffe mal das es da noch was
gibt ;-)
Ansonsten danke ich euch schon mla für eure Ideen und Hilfe.
Dennis Grevenstein
>
> So ists. Das wäre ja dann die "letzte" Lösung und teuer dafür was zu
> erhalten was es nicht mehr "gibt" Allerdings wird das , wenn es keine
> andere Lösung gibt angestrebt um eine Notlösung für den Ausfall zu
> haben um eine ERP für neue HArdware zu schreiben.
Was spricht dagegen das als kalkulierte Uebergangsloesung zu
verwenden? Man besorgt eine grosse RM gleich doppelt und bietet
parallel eine Portierung der Software (oder Neuentwicklung) auf
einer aktuellen Plattform an.
Ich gehe mal davon aus, dass der Kunde durchaus Gruende hatte
eine stabile Plattform zu verwenden und nicht allzu gern auf eine
wackelige Emulation wechseln will. Den Linux-MIPS-Port in allen
Ehren, aber den Vergleich mit einem Reliant UNIX haelt der wohl
nicht stand. Vor allem ist die Zukunftsprognose bei sowas extrem
unsicher. Keiner kann garantieren, dass eine bestimmte hardware
auch noch in zwei bis drei Jahren oder der naechsten groesseren
kernel-Aenderung brauchbar unterstuetzt wird. Bei den nicht-x86
Plattformen haengt sehr viel davon ab, ob ein paar wenige Entwickler
Zeit, Lust oder passende Hardware verfuegbar haben.
Bernd Eckenfels
> Was spricht dagegen das als kalkulierte Uebergangsloesung zu
> verwenden? Man besorgt eine grosse RM gleich doppelt und bietet
> parallel eine Portierung der Software (oder Neuentwicklung) auf
> einer aktuellen Plattform an.
Ich denke auch, wenn man sich bereiterklärt einen RM Server zu übernehmen
bekommt man dafür noch (Entsorgungs) Geld.
Gruss
Bernd
PS: dem kunden sollte das ne lehre sein, und er soll sich kein ERP mehr
selbt schreiben :)
Peter J. Holzer
>> Quellverzeichnisse mit Debian-Patches uebersetzt man ueblicherweise mit so
>> was wie
>>
>> $ dpkg-buildpackage -us -uc -rfakeroot
>>
>> dann faellt am Ende ein normales .deb-Packet und fast ein halbes Dutzend
>> debian spezifische Dateien raus.
>
> NUn das zählt für den Fall, das es ein solches Quellpaket ist. Aber
> das knn ich nicht erkennen.
Nein. Das Quellpaket ist eines der Ergebnisse von dpkg-buildpackage.
> Mich verwirrtt eben der Ordner mit den Debian details und ich weiß
> nicht was sich damit anfangen soll.
Ein Debian-Package bauen, vermutlich. So wie von Deinem Vorposter
geschildert.
hp
Rainer Weikusat
[...]
> PS: dem kunden sollte das ne lehre sein, und er soll sich kein ERP mehr
> selbt schreiben :)
Im gegebenen Fall waere dann auch noch die Anwendung von dem
'end-of-life' betroffen, was die Situation wohl nicht verbessert
haette.
HerrBrand
> > PS: dem kunden sollte das ne lehre sein, und er soll sich kein ERP mehr
> > selbt schreiben :)
Nun, das ist erstens mal in dem Sinn nciht selbst geschrieben worden,
sondern für sie entwickelt, aber eben unter X.Basic.
Zweitens sehich das als die bessere Lösung an ein ERp auf die Fa
schrieben zu lassen,d enn keine der vorhandenen ERP System kann die
kompletten Strukturen einer Fa abbilden. UNd das umschreiben kostet
mit der Anschaffung grundsätzlich mehr, sofern es überhaupt machbar
ist, als eine Individuallösung.
Meien letzte ERp Einführung habe ich mit SAP B1 mitmachen dürfen. Oh
Gott, was für ein Krampf. Jeder der behauptet einen Standardsoftware
leifern zu können um die Prozesse einer Fa zu unterstützen, der
spricht nicht die Wahrheit.
@dennis
Nun, da gebe ich dir recht was das anschasffen einer Rm betrifft. Doch
da mußt du genau die finden, die auf das System paßt das sich da
befindet.
Das jetzte was die Herren des Kunden selbst gefunden hatten war bei
ebay. und soweit ich das mitbeekommen habe paßt das nciht ganz.
Aber wie gesagt. Sollte es da keine Lösung geben, wird eh ein neues
ERp System angeboten.
Das sind wir ja sozusagen schon dran.
Rainer Weikusat
[...]
> Den Linux-MIPS-Port in allen Ehren, aber den Vergleich mit einem
> Reliant UNIX haelt der wohl nicht stand. Vor allem ist die
> Zukunftsprognose bei sowas extrem unsicher. Keiner kann garantieren,
> dass eine bestimmte hardware auch noch in zwei bis drei Jahren oder
> der naechsten groesseren kernel-Aenderung brauchbar unterstuetzt
> wird.
Das kann, im Gegensatz zu einem 'Reliant UNIX' allerdings
grundsaetzlich jeder sicherstellen, denn man bekommt den Quellcode und
darf ihn aendern, ohne sich auch nur um die Ansichten der sogenannten
'Entwickler' kuemmern zu muessen. Die Geraete, mit denen ich es
hauptsaechlich zu tun habe, haben ARM9-Prozessoren und benutzen Linux
2.4 (.36.3), urspruenglich, weil das die Version war, fuer die es
wenigstens irgendeine Unterstuetzung seitens des Hardwareherstellers
gab, mittlerweile auch, weil es entschieden zu nervenaufreibend waere,
das, was 'die Entwickler' in 2.6 rasant ausser Funktion setzen, im
selben Tempo zu reparieren. Das sogenannte ARM-Linux-Projekt hat
allerdings vor Jahren beschlossen, Leute wo moeglich zu noetigen, 2.6
zu benutzen, 2.4 basierte Fragen (oder gar Antworten auf solche
Fragen) fuehren regelmaessig zu Psychoterror-Attacken der
entsprechenden 'wichtigen Leute'. Jetzt habe ich allerdings den Code
und bin vollkommen imstande, damit alles zu machen, was jemand von ihm
wollen koennte und muss mich weder um Russell Kings
'policy'-Entscheidungen kuemmern, noch mich mit seinem rueden Benehmen
auseinandersetzen.
In dieser Hinsicht wuerde ich mir eher Sorgen um Compiler machen,
denn die Leute, die an gcc entwickeln, finden ja im allgemeinen nichts
dabei, den Gegenwert von buchstaeblich hunderten von Mannjahren an
Arbeit 'ueber Nacht' zu vernichten, weil sich irgendjemandes unwesentliche
Meinung ueber die Grenze zwischen erlaubten und sinnvollen
Interpretationen der entsprechenden Norm-Texte geaendert hat.
Peter J. Holzer
> Dennis Grevenstein <dennis.gr...@gmail.com> writes:
>> Den Linux-MIPS-Port in allen Ehren, aber den Vergleich mit einem
>> Reliant UNIX haelt der wohl nicht stand. Vor allem ist die
>> Zukunftsprognose bei sowas extrem unsicher. Keiner kann garantieren,
>> dass eine bestimmte hardware auch noch in zwei bis drei Jahren oder
>> der naechsten groesseren kernel-Aenderung brauchbar unterstuetzt
>> wird.
>
> Das kann, im Gegensatz zu einem 'Reliant UNIX' allerdings
> grundsaetzlich jeder sicherstellen, denn man bekommt den Quellcode und
> darf ihn aendern, ohne sich auch nur um die Ansichten der sogenannten
> 'Entwickler' kuemmern zu muessen.
> In dieser Hinsicht wuerde ich mir eher Sorgen um Compiler machen,
> denn die Leute, die an gcc entwickeln, finden ja im allgemeinen nichts
> dabei, den Gegenwert von buchstaeblich hunderten von Mannjahren an
> Arbeit 'ueber Nacht' zu vernichten, weil sich irgendjemandes unwesentliche
> Meinung ueber die Grenze zwischen erlaubten und sinnvollen
> Interpretationen der entsprechenden Norm-Texte geaendert hat.
Allerdings gilt für den gcc das gleiche wie für den Linux-Kernel: Du
hast den Source-Code und darfst den nach Belieben weiterentwickeln. Wenn
also Deine (für Dich naturgemäß wesentliche) Meinung von der anderer
Leute abweicht, bist Du an deren Interpretation nicht gebunden.
hp
Rainer Weikusat
Das tue ich ja auch bereits in dem Rahmen, wie es fuer den gegebenen
Fall notwendig ist. Im Gegensatz zu dem Kernel ist das aber ein technisch
vollkommen nutzloser overhead. Allerdings wollte ich im wesentlichen
zum Ausdruck bringen, dass ich es fuer sehr viel wahrscheinlicher
halte, das man fuer irgendwelche Hardware, fuer die es wenigstens mal
einen Linux-Port gab, mit vertretbarem Aufwand auch einen
funktionieren, kompilierten Linux-kernel bekaeme, als das man sich
darauf verlassen koennte, noch einen Compiler zu finden, mit dessen
Hilfe man entsprechend alte Anwendungssoftware auch noch dafuer
uebersetzt bekommt, und ggf koennte man noch nicht mal den theoretisch
funktionstuechtigen Kernel uebersetzen, ohne sehr viel mehr von dem
Code ueberpruefen zu muessen, also fuer die reine Loesung des
eigentlichen technischen Problems notwendig waere, dh das Dennis'
'unsichere Zukunftsprognose' meiner Meinung nach zwar korrekt ist, das
aber keine 'Linux-Problem' sondern ein 'gcc-Problem' waere.
> Wenn also Deine (für Dich naturgemäß wesentliche) Meinung von der
> anderer Leute abweicht, bist Du an deren Interpretation nicht
> gebunden.
Ich habe zu diesem Thema ueberhaupt keine Meinung, ausser insofern als
das ich die meisten 'Compiler-Optimierungen' fuer 'klassische'
"premature-Optimization" Zeitverschwendung halte
("Giesskannenoptimierung" wird nicht dadurch sinnvoller, dass eine
Maschine sich an ihr versucht), aber ich habe kleine Berge von
altem Code (vermutlich bedeutend weniger als viele andere Leute), der
bestimmte Funktionen vollkommend zufriedenstellend erfuellt. Und
gegenueber dieser Tatsache halte ich jede Meinung bezueglich einer
Textauslegung fuer vollkommen unwesentlich.
Joerg Scheurich aka MUFTI
> denn die Leute, die an gcc entwickeln, finden ja im allgemeinen nichts
> dabei, den Gegenwert von buchstaeblich hunderten von Mannjahren an
> Arbeit 'ueber Nacht' zu vernichten, weil sich irgendjemandes unwesentliche
> Meinung ueber die Grenze zwischen erlaubten und sinnvollen
> Interpretationen der entsprechenden Norm-Texte geaendert hat.
Kannst Du dazu ein anschauliches Beispiel posten ? Es ist sonst nur schwer
zu glauben.
Immerhin wird die Arbeit von hunderten von Mannjahren dann nicht komplett
vernichtet, wenn man die Arbeit der hundert Mannjahre einfach nur
umschreiben muss...
so long
MUFTI
--
Anwendungen das "Works with Windows Vista" Logo von verdient haben
Unternehmen Produktname
AOL LLC. STREBEN SIE 6 AN
Micro$oft Knowledge Base Artikel-ID:933305 Version:4.1
Dennis Grevenstein
>
> Allerdings wollte ich im wesentlichen
> zum Ausdruck bringen, dass ich es fuer sehr viel wahrscheinlicher
> halte, das man fuer irgendwelche Hardware, fuer die es wenigstens mal
> einen Linux-Port gab, mit vertretbarem Aufwand auch einen
Mein Gedankengang war eher, dass man sich nicht nur irgendeinen
kernel mit irgendeinem System drum herum wuenscht, das irgendwie
die Kiste zum booten bringt, sondern dass man in der Regel etwas
moechte, das stabil und schnell laeuf und fuer das man updates
und patches bekommt.
Den Aufwand einen kernel zu pflegen halte ich kaum fuer vertretbar,
wenn man die Arbeitszeit alternativ auch gleich in die Poertierung
der Anwendung stecken koennte.
Rainer Weikusat
<rusm...@helpdesk.bera.rus.uni-stuttgart.de> writes:
>> In dieser Hinsicht wuerde ich mir eher Sorgen um Compiler machen,
>> denn die Leute, die an gcc entwickeln, finden ja im allgemeinen nichts
>> dabei, den Gegenwert von buchstaeblich hunderten von Mannjahren an
>> Arbeit 'ueber Nacht' zu vernichten, weil sich irgendjemandes unwesentliche
>> Meinung ueber die Grenze zwischen erlaubten und sinnvollen
>> Interpretationen der entsprechenden Norm-Texte geaendert hat.
>
> Kannst Du dazu ein anschauliches Beispiel posten ? Es ist sonst nur schwer
> zu glauben. Immerhin wird die Arbeit von hunderten von Mannjahren
> dann nicht komplett vernichtet, wenn man die Arbeit der hundert
> Mannjahre einfach nur umschreiben muss...
Es ist nicht moeglich, ein Beispiel fuer falsche Verhalten eines
englischen Koenigs zu geben, weil fuer den per Definition 'king can do
no wrong' gilt.
Rainer Weikusat
Zwecks besserer Verstaendlichkeit eine Ergaenzung: Es ist nicht
moeglich, existierenden C-Code fuer Linux zu benutzen, ohne
gleichzeitig eine gcc-Version am Leben zu erhalten, die diesen korrekt
zu uebersetzen vermag. Es gibt einen breiten Konsens das dies eine
gute Sache sei, und ueber den zu diskutieren ist zwecklos.
Joerg Scheurich aka MUFTI
> moeglich, existierenden C-Code fuer Linux zu benutzen, ohne
> gleichzeitig eine gcc-Version am Leben zu erhalten, die diesen korrekt
> zu uebersetzen vermag.
Hmm, es gibt nicht nur einen C-Compiler fuer Linux.
gcc ist auch nicht der einzige open source C compiler fuer Linux.
Dann gibt es noch C-Compiler, die den gcc als Backend benutzen, aber
ihre eigenen Ideen in Sachen Syntax haben.
so long
MUFTI
--
Chatetiquette
... Seien Sie Sie höflich und nicht Personen Dachs, wenn Sie nach
Hilfe fragen.
Micro$oft Knowledge Base Artikel-ID: 178294 Version: 3.1
Peter J. Holzer
> Rainer Weikusat <rwei...@mssgmbh.com> writes:
>> Joerg Scheurich aka MUFTI
>> <rusm...@helpdesk.bera.rus.uni-stuttgart.de> writes:
>>>> In dieser Hinsicht wuerde ich mir eher Sorgen um Compiler machen,
>>>> denn die Leute, die an gcc entwickeln, finden ja im allgemeinen nichts
>>>> dabei, den Gegenwert von buchstaeblich hunderten von Mannjahren an
>>>> Arbeit 'ueber Nacht' zu vernichten, weil sich irgendjemandes unwesentliche
>>>> Meinung ueber die Grenze zwischen erlaubten und sinnvollen
>>>> Interpretationen der entsprechenden Norm-Texte geaendert hat.
Die Grenze zwischen erlaubt und sinnvoll? Was erlaubt ist, ist also
nicht sinnvoll und was sinnvoll ist, ist nicht erlaubt? Das könnte es
natürlich etwas schwierig machen, sinnvollen C-Code zu schreiben :-)
>>> Kannst Du dazu ein anschauliches Beispiel posten ? Es ist sonst nur schwer
>>> zu glauben. Immerhin wird die Arbeit von hunderten von Mannjahren
>>> dann nicht komplett vernichtet, wenn man die Arbeit der hundert
>>> Mannjahre einfach nur umschreiben muss...
>>
>> Es ist nicht moeglich, ein Beispiel fuer falsche Verhalten eines
>> englischen Koenigs zu geben, weil fuer den per Definition 'king can do
>> no wrong' gilt.
>
> Zwecks besserer Verstaendlichkeit eine Ergaenzung: Es ist nicht
> moeglich, existierenden C-Code fuer Linux zu benutzen, ohne
> gleichzeitig eine gcc-Version am Leben zu erhalten, die diesen korrekt
> zu uebersetzen vermag.
Das ist eine Tautologie. Natürlich kann man Source-Code nur dann benützen,
wenn man auch einen Compiler hat, der ihn übersetzen kann.
Wenn Du damit aber ausdrücken willst, dass es unmöglich ist, C-Code zu
schreiben, der mit verschiedenen Versionen des GCC compiliert werden
kann, dann ist das schlicht und einfach Unsinn. Wenn ich irgendeinen
C-Code von mir nach 1989 (Erscheinungsdatum des ersten C-Standards)
mit einem aktuellen GCC nicht auf Anhieb übersetzen kann, dann liegt das
in 90% der Fälle an einem vergessenen #include, was erstens trivial zu
fixen ist und zweitens nicht ein Problem des Compilers sondern der
Systemlibraries ist. Und das übersetzte tut dann meistens auch, was es
soll (wobei natürlich die Wahrscheinlichkeit, dass Code, den ich mir
seit 19 Jahren nicht mehr angeschaut habe, Bugs enthält, schon recht
groß ist - aber das sind meine Bugs, und die haben nichts mit dem GCC zu
tun - die könnten mich mit einem Intel-, Sun- oder HP-C-Compiler genauso
beißen).
Wenn Dein "C-Code" immer nur mit einer bestimmten Version des GCC
funktioniert, dann ist es kein C-Code, sondern irgendwas, was sich
zufällig mit dieser GCC-Version übersetzen lässt.
> Es gibt einen breiten Konsens das dies eine gute Sache sei, und ueber
> den zu diskutieren ist zwecklos.
Ob es eine gute Sache ist, dass C der Implementation so große Freiräume
gibt, darüber kann man durchaus geteilter Meinung sein. Aber die Grenzen
dieser Freiräume sind doch recht genau abgesteckt, und man kann sich als
Programmierer mit ein wenig Vorsicht weit genug von Ihnen entfernt
halten. Oder man kann eine Sprache verwenden, die den eigenen Vorlieben
mehr entgegenkommt. Ich schreibe ja auch fast keinen C-Code mehr.
hp