was braucht ein "AMINUX" ? - amiga-news.de Forum

amiga-news.de Forum > AROS und Amiga-Emulatoren > was braucht ein "AMINUX" ?

[ - Suche - Neue Beiträge - Registrieren - Login - ]

1 -2- 3

[ - Beitrag schreiben - ]

26.09.2005, 16:08 Uhr

FischX
Posts: 436
Nutzer

@schluckebier:
Ich finde den sudo Ansatz der von Ubuntu verwendet wird schon sehr gut, ich würde sogar weiter gehen das für unsere Zwecke nur sichergegangen werden muss dass ein localer User und nicht ein Programm oder aus dem Netzwerk zugegriffen wird.
Da würde für den Nützer einfach ein "wollen sie in den piviligierten Modus wechseln? j/n" Fenster reichen die Anwendung muss dann nur noch überprüfen das der Klick auf "ja" wirklich von etwa dev/mouse gekommen ist.

[ - Antworten - Zitieren - Direktlink - ]

26.09.2005, 16:32 Uhr

Solar
Posts: 3680
Nutzer

Die Alternative ist eine Rechteverwaltung, die sich konsistent durch das System zieht, statt ein Rechte-Flag-Prinzip, auf das man im Laufe der Jahrzehnte dann sticky bits und sudo und ACL's draufgeflanscht hat...

...aber das ist halt der Nachteil, wenn man Linux als Basis nimmt.

[ - Antworten - Zitieren - Direktlink - ]

26.09.2005, 16:50 Uhr

FischX
Posts: 436
Nutzer

@Solar:
das sticky bit gab es schon immer, und gehört zur Rechtephilosophie von Un*x wie chmod. ACL's sind auch kein patch sondern gut durchdacht ( und auch schon ein bischen älter als Linux), sudo das irgend ein fauler Student in Berkeley sich mitte der 80 er einfallen gelassen hat um sich die arbeit zu erleichtern bricht auch nicht mit der Philosophie sondern kann man einfach als erweiterung von su sehen.

alles FAIK

[ Dieser Beitrag wurde von FischX am 26.09.2005 um 16:51 Uhr editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

27.09.2005, 14:06 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von schluckebier:

Zitat:
Original von Holger:
Ansonsten existieren die durch neuere APIs verbesserte Linux-Umgebung (oder komplett neue Umgebung)
Den Teil verstehe ich nicht, es sei denn das "oder" in der Klammer wäre ein Fehler. Inwiefern willst du die Linux-Umgebung durch die Amiga-APIs verbessern?

Neuere APIs, man möge sie auch aufgrund unserer Inspirationsquelle "Amiga"-APIs nennen, aber wenn sie das konventionelle GNU/Linux verbessern sollen, entsprechen sie nicht 1:1 den alten Amiga-APIs. Beispiele waren public-screens für Gnome o. KDE oder eben Laufwerksnamen, einheitlich für shell- und desktop-Programme.
Komplett neue Umgebung hätte dagegen mehr Ähnlichkeit mit der Hosted-Version von AROS, wobei durch Features wie MUI/ReAction->GTK/Qt Wrapper das Ganze transparenter gestaltet wäre. Ähnlich MOS, wenn es eine weitere Box oder Quark-Services geben würde.

Zitat:
Das würde mir erst einmal vollkommen reichen, so hätte man das Beste aus beiden Welten ständig zur Verfügung, ohne dass man die "Nahtstelle" bemerken würde. E-UAE ist zwar schön, eingebettet in den Desktop wäre es allerdings noch schöner (eben so wie z.B. in der A/Box von MorphOS).

Definitiv eine praktische Sache, für eine Weiterentwicklung wäre die Abhängigkeit vom urheberrechtlich geschützten Kickstart ein Hemmschuh.
Und der AROS-Ansatz, erstmal alle Altlasten nachprogrammieren und erst danach über potentielle Weiterentwicklung oder generelle Zielstellung nachdenken, verschwendet in meinen Augen zu viele Resource.

Zitat:
Wenn man sowas als "neues AmigaOS" angeht, dann muss es eben auch sehr amiga-like sein. Für mich (und DJBase auch, wie es aussieht) bedeutet das u.a., dass auch die Amiga-Verzeichnisstruktur vorhanden sein muss und kein unixoider Verzeichnisbaum.

Die doppelt-verketteten Listen von Exec oder nicht nicht offengelegte Struktur von Devices+Assigns im DOS sieht man auch nicht und keinen würde es stören, wenn die Datenstruktur intern anders wäre.
Wen interessiert zum Beispiel die tatsächliche Verzeichnisstruktur im Handy?
Ich denke, daß viel Amiga-User eine Amiga-ähnliche Verzeichnisstruktur sehen wollen, ist jetzt jedem klar.

Zitat:
Ich wäre aber durchaus mit einem "Linux-Desktop + Amiga-Aufsatz" sehr zufrieden. Tatsächlich würde mir das sogar ausgesprochen gut gefallen, auch wenn es halt kein neues AmigaOS ist.

Eventuell ja weil es "kein neues AmigaOS ist". Es ist schonmal untypisch, weil hier erstmalig nicht ein Entwickler anfängt, irgendetwas zu programmieren, daß er für Amiga-like, bzw. einen würdigen AmigaOS-Nachfolger hält, sondern Entwickler und Anwender miteinander darüber diskutieren, was gewünscht und was machbar ist.

Meine Erfahrung bei der Software-Entwicklung ist: einen Monat länger im Vorfeld diskutiert, spart ein Jahr Entwicklungszeit am Ende (grob geschätzt, keine präzisen Meßdaten

)

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

27.09.2005, 14:19 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von schluckebier:
Aber was wäre die Alternative, wenn man Multiuser-Betrieb haben möchte? Dass jede Software für jeden Benutzer lokal installiert wird?

Nein, es gibt zwei Dinge, die dabei Probleme bereiten. Das eine ist die Rechteverwaltung des Systems, die teilweise auf vorsintflutlichen Konzepten basiert (das meinte Solar vemutlich auch), das andere ist aber auch die Umsetzung von Anwendungsprogrammierern.
Daß zum Beispiel nach mehreren Jahren WinXP-Marktpräsenz (von der NT-Linie ganz zu schweigen), immer noch Programme en masse erscheinen, die ohne Administratorrechte nicht richtig funktionieren, liegt nicht hauptsächlich an Microsoft.
Wenn sie die Möglichkeit, sich als Administrator einzuloggen, generell unterbunden hätten, wäre das System auf den ersten Blick wesentlich unkomfortabler geworden, würde aber heute keine solchen Probleme mehr haben.
Wenn eine Installationroutine nicht in der Lage ist, sich die nötigen Rechte per Dialog vom User einzuholen (einige beweisen, daß es geht), dann würde sie ohne die Möglichkeit des Einloggens als Administrator ganz schnell vom Markt verschwinden.

Für Amiga-Programme gilt ähnliches. Programme, die Konfigurationen brav nach ENV: oder ENVARC: schreiben, hätten keine Probleme. Die, die meinen, ins eigene Installationsverzeichnis oder gar nach S: oder SYS: usw. schreiben zu müssen, wären in einer Multi-User-Umgebung typische Problemkandidaten.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

27.09.2005, 14:27 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von FischX:
Da würde für den Nützer einfach ein "wollen sie in den piviligierten Modus wechseln? j/n" Fenster reichen die Anwendung muss dann nur noch überprüfen das der Klick auf "ja" wirklich von etwa dev/mouse gekommen ist.

So ähnlich funktioniert es ja auch, z.B. unter Windows, wenn man ein leeres Passwort gesetzt hat (und das Programm konform geschrieben wurde-fast nie also). Ob man das Sicherheitsrisiko eines leeren Paßworts haben möchte, bleibt jedem selbst überlassen.
Die Frage "wollen sie in den piviligierten Modus wechseln?" zeigt aber schon die Schwäche der meisten Betriebssysteme. Eigentlich will ich gar keine Entweder-Oder Entscheidung.
Im Idealfall würde ein Programm die benötigten Rechte (z.B. Zugriff aufs Netzwerk, auf CD-Brenner, Direktzugriff auf Festplatte, Audio-Hardware) auflisten, welche aufgrund der Art des Programms auch für Anfänger verständlich wären (ein Browser braucht keinen SCSI-Direktzugriff), und auch nur diese bekommen, wenn der Anwender sie bestätigt.
Natürlich sollte man solche Zugeständnisse für installierte Programme auch dauerhaft speichern können, um nicht jedesmal auf's Neue Dialoge ausfüllen zu müssen.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

27.09.2005, 14:36 Uhr

schluckebier
Posts: 1059
Nutzer

Zitat:
Original von Holger:
Neuere APIs, man möge sie auch aufgrund unserer Inspirationsquelle "Amiga"-APIs nennen, aber wenn sie das konventionelle GNU/Linux verbessern sollen, entsprechen sie nicht 1:1 den alten Amiga-APIs. Beispiele waren public-screens für Gnome o. KDE oder eben Laufwerksnamen, einheitlich für shell- und desktop-Programme.

So ganz will mir das aber immer noch nicht einleuchten, vor allem in Hinblick auf die "normale" KDE-/Gnome-/Sonstwas-Entwicklung. Willst du diese "neueren" APIs in die offizielle Entwicklung des jeweiligen Desktops einbringen (da sehe ich heftigste Grundsatzdiskussionen voraus :o)) oder dann doch eher einen Aufsatz basteln? Also eher "zusätzliche" als "neuere"?

Zitat:
Definitiv eine praktische Sache, für eine Weiterentwicklung wäre die Abhängigkeit vom urheberrechtlich geschützten Kickstart ein Hemmschuh.

Der Kickstart darf natürlich nie Bestandteil des (wie auch immer gearteten) Pakets sein, klare Sache. Aber das ist bei UAE ja auch nicht der Fall, der geneigte Benutzer muss sich halt ein Image seines ROMs machen oder Amiga Forever kaufen oder sonstwas.

Zitat:
Und der AROS-Ansatz, erstmal alle Altlasten nachprogrammieren und erst danach über potentielle Weiterentwicklung oder generelle Zielstellung nachdenken, verschwendet in meinen Augen zu viele Resource.

Stimmt, das fänd' ich auch wenig sinnvoll.

Zitat:
Die doppelt-verketteten Listen von Exec oder nicht nicht offengelegte Struktur von Devices+Assigns im DOS sieht man auch nicht und keinen würde es stören, wenn die Datenstruktur intern anders wäre.

Der Unterschied ist der, dass man nicht mal eben durch Anklickern eines Piktogramms in Listen von Exec reinkommt, in die Shell aber schon. ;o)

Wer wie ich von Anfang an immer die Shell benutzt hat, der weiß sie als Werkzeug auch zu schätzen. Und wenn man sich viel in der Shell bewegt, dann weiß man auch genau, was wo zu finden ist, eben wegen der sehr übersichtlichen Struktur. Ich bin zwar auch ständig in der Linux-Konsole zugange, dort weiß ich aber nicht immer, wo sich was befindet. Kannst du z.B. aus dem Kopf sagen, wo die einzelnen Konfigurationsdateien von X liegen?

Zitat:
Wen interessiert zum Beispiel die tatsächliche Verzeichnisstruktur im Handy?

Stimmt, interessiert mich nicht, aber ich finde auch die genaue Anordnung der Heizdrähte im Toaster eher uninteressant. Mit anderen Worten: wo keine Shell, da egal. :o)

Zitat:
Ich denke, daß viel Amiga-User eine Amiga-ähnliche Verzeichnisstruktur sehen wollen, ist jetzt jedem klar.

Also schwebt dir sowas wie eine Pfadübersetzung vor?

Zitat:
Zitat:
Ich wäre aber durchaus mit einem "Linux-Desktop + Amiga-Aufsatz" sehr zufrieden. Tatsächlich würde mir das sogar ausgesprochen gut gefallen, auch wenn es halt kein neues AmigaOS ist.
Eventuell ja weil es "kein neues AmigaOS ist".

Ja, definitiv. An einen Aufsatz z.B. für Linux stellt man natürlich weniger Ansprüche, als man für ein Ersatz-Betriebssystem haben würde. Geht mir zumindest so.

Zitat:
Es ist schonmal untypisch, weil hier erstmalig nicht ein Entwickler anfängt, irgendetwas zu programmieren, daß er für Amiga-like, bzw. einen würdigen AmigaOS-Nachfolger hält, sondern Entwickler und Anwender miteinander darüber diskutieren, was gewünscht und was machbar ist.

Ich weiß leider immer noch nicht ganz genau, worauf das im Endeffekt hinausläuft bzw. hinauslaufen soll. Wenn es ein eingebetteter UAE sein soll, dann wäre die Amiga-Ähnlichkeit m.E. gar nicht so wichtig, weil man vom Drumrum sowieso nichts oder nicht viel mitbekommen würde, denn das in der Box laufende Programm würde sich ja nach Möglichkeit so nativ (aus Host-Sicht) wie irgend machbar geben, oder habe ich das grundlegend missverstanden?

[ - Antworten - Zitieren - Direktlink - ]

27.09.2005, 14:41 Uhr

NoImag
Posts: 1050
Nutzer

Zitat:
Original von Holger:
Wenn sie die Möglichkeit, sich als Administrator einzuloggen, generell unterbunden hätten, wäre das System auf den ersten Blick wesentlich unkomfortabler geworden, würde aber heute keine solchen Probleme mehr haben.

Hier kann ich dir nicht ganz folgen. Wenn du für bestimmte Dinge Administrator-Rechte benötigst, wie willst du diese Dinge erledigen, ohne dich als Administrator einzuloggen?

Zitat:
Wenn eine Installationroutine nicht in der Lage ist, sich die nötigen Rechte per Dialog vom User einzuholen (einige beweisen, daß es geht),

Oder meinst du, für bestimmte Aufgaben wird jedesmal automatisch angefragt, ob du dazu berechtigt bist, so wie bei MacOS X? Allerdings gibt es auch bei MacOS X noch einen "root" und manchmal muss man sich als "root" einloggen.

Zitat:
Für Amiga-Programme gilt ähnliches. Programme, die Konfigurationen brav nach ENV: oder ENVARC: schreiben, hätten keine Probleme. Die, die meinen, ins eigene Installationsverzeichnis oder gar nach S: oder SYS: usw. schreiben zu müssen, wären in einer Multi-User-Umgebung typische Problemkandidaten.

Auch wenn S: schon seit Ewigkeiten nicht mehr systemkonform ist (OS2.0?), dies könnte man noch hinbiegen. Anders sieht dies mit PROGDIR: aus, dies ist bisher legal, macht aber natürlich bei einem Multiusersystem Probleme.

Tschüß,

[ - Antworten - Zitieren - Direktlink - ]

27.09.2005, 14:41 Uhr

FischX
Posts: 436
Nutzer

@Holger:
Man könnte das auch ohne Dialog machen so das zB ein Klick auf die Prefs als "Gate" gewertet wird (überprüfung das die Aktivierung tatsächlich aufgrund einer gewollten Interaktion des Users) der Benutzer selber merkt davon nichts trozdem bleibt dieser Weg für Viren ect versperrt.

@all:
könnte sich jemand Enlightenment als basis für einen WB-Ersatz vorstellen?

[ - Antworten - Zitieren - Direktlink - ]

27.09.2005, 16:59 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von schluckebier:
So ganz will mir das aber immer noch nicht einleuchten, vor allem in Hinblick auf die "normale" KDE-/Gnome-/Sonstwas-Entwicklung. Willst du diese "neueren" APIs in die offizielle Entwicklung des jeweiligen Desktops einbringen (da sehe ich heftigste Grundsatzdiskussionen voraus :o)) oder dann doch eher einen Aufsatz basteln? Also eher "zusätzliche" als "neuere"?

Ob "zusätzliche" oder "neuere" APIs hängt natürlich im Einzelfall vom Ergebnis genau dieser Grundsatzdiskussion ab. Es ist natürlich immer besser, wenn ein Feature in die offizielle Code-Basis aufgenommen wird.
Solange nicht grundsätzliche Dinge entfernt werden, die vorher funktioniert haben, glaube ich nicht, daß es sooo schwer ist.
Manchmal hilft es, den Amiga-Background nicht zu erwähnen, und einen an das gewohnte Linux-Umfeld angepaßten Namen zu verwenden.
Aus public-screen wird halt etwas wie "named virtual desktop", einfach deshalb, weil technisch alles notwendige schon vorhanden ist und unter Linux schon einen Namen hat. Neu wäre dann nur, daß das Einstellungsprogramm für den Desktop optional Namen für die Desktops zuläßt, und die Programme sich den Namen des Desktops merken, dem sie zugeordnet werden.
Diese Desktops ziehbar wie amiga-screens zu machen, ist dann nur eine weitere Option, die es aber auch schon gibt (ah, ich sehe, jemand kennt enlightenment

)
Und zusammen kann man es wie public-screens benutzen.

Zitat:
Der Kickstart darf natürlich nie Bestandteil des (wie auch immer gearteten) Pakets sein, klare Sache. Aber das ist bei UAE ja auch nicht der Fall, der geneigte Benutzer muss sich halt ein Image seines ROMs machen oder Amiga Forever kaufen oder sonstwas.

Klar, aber besser sind immer Dinge, die man auch Linux beilegen kann. Die meisten Distributionen versuchen immer alles, was man frei kriegen kann, zu integrieren und das erspart einem das Übersetzen von verschiedenen Versionen für die jeweilige Distri.

Zitat:
Der Unterschied ist der, dass man nicht mal eben durch Anklickern eines Piktogramms in Listen von Exec reinkommt, in die Shell aber schon. ;o)

Gibt auch für Amiga einen PROC-Handler

Und Systemmonitore; die Frage ist nicht unbedingt, ob man in die Interna reinkommt, sondern, ob man das muß, um zum Ziel zu gelangen.

Zitat:
Kannst du z.B. aus dem Kopf sagen, wo die einzelnen Konfigurationsdateien von X liegen?

Um Himmels Willen

Zitat:
Also schwebt dir sowas wie eine Pfadübersetzung vor?

Vielleicht, aber nicht unbedingt so, wie Du jetzt denkst. /proc ist sowieso virtuell, /dev in einigen Systemen inzwischen auch, niemand sagt, daß die realen Pfade auf der Platte die sein müssen, die das System (egal ob GNU/Posix oder Amiga) sieht.
Welche tatsächlich auf der Platte sind, hängt vom Anwendungsfall ab. Bootet man Amithlon like und startet ab und zu mal ein Linux Programm kann das anders sein, als wenn man sein Linux-System bootet und ab und zu mal ein Amiga-Programm startet.

Zitat:
Ich weiß leider immer noch nicht ganz genau, worauf das im Endeffekt hinausläuft bzw. hinauslaufen soll.

Wenn das klar wäre, bräuchten wir ja gar nicht drüber nachzudenken/ diskutieren

Hier treffen verschiedene Dinge aufeinander, die man zwar unabhängig voneinander betrachten könnte, deren Lösungen man aber genausogut hinterher in einer Distribution zusammenfassen könnte, die evtl. eine ziemlich runde Sache werden könnte.

Linux Programme mit Amiga Look&Feel ausführen
a) durch Desktop-Konfiguration, Skin, etc.
b) durch funktionale Erweiterung der Linux-Toolkits

alte Amiga-Programme integriert ausführen
a) durch einen minimalistischen Wrapper, der auf den Linux-Toolkits aufsetzt
b) durch einen UAE, der wesentlich transparenter als der bisherige läuft

Neuentwicklungen
a) AROS-like, auf einer x86-Version der Amiga-APIs, die hosted läuft
b) basierend auf den funktional erweiterten Toolkits aus Punkt 1b)

wahrscheinlich gibts noch mehr Ansätze...
Ideen, Ideen, Ideen! Leute schreibt, was Euch in den Sinn kommt.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

27.09.2005, 17:09 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von NoImag:
Hier kann ich dir nicht ganz folgen. Wenn du für bestimmte Dinge Administrator-Rechte benötigst, wie willst du diese Dinge erledigen, ohne dich als Administrator einzuloggen?

->

Oder meinst du, für bestimmte Aufgaben wird jedesmal automatisch angefragt, ob du dazu berechtigt bist, so wie bei MacOS X? Allerdings gibt es auch bei MacOS X noch einen "root" und manchmal muss man sich als "root" einloggen.

Im Prinzip so, allerdings 1.) nicht bei jeder Aktion, sondern nur bei unbekannten Programmen, normalerweise Installationsroutinen, worauf für das neu installierte Programm die Berechtigung dauerhaft gespeichert wird, meinethalben mit timestamp und checksum, um bei Manipulation die Rechte vorsorglich wieder zu entziehen. Und 2.) sollte die Notwendigkeit, sich doch mal als root einzuloggen, in einem ordentlichen System nicht mehr existieren.
Unter WinXP mußte ich mich bislang sehr selten als Administrator einloggen und es lag immer an einem Drittprogramm, niemals an der sw von XP. Vorbeugender Nachtrag: ich bin als "Benutzer" angemeldet, weder "Hauptbenutzer", noch zur Gruppe der "Administratoren" gehörend. Ich mein es so, wie es sein sollte

Zitat:
Auch wenn S: schon seit Ewigkeiten nicht mehr systemkonform ist (OS2.0?), dies könnte man noch hinbiegen. Anders sieht dies mit PROGDIR: aus, dies ist bisher legal, macht aber natürlich bei einem Multiusersystem Probleme.

Im Notfall kann man alles hinbiegen. Man kann z.B. sämtliche Änderungen am System virtualisieren, so daß sie nur vom ausführenden Account sichtbar sind.
Dies sind aber immer Notlösungen. Im Idealfall sollte die jeweilige Software selbst am besten sagen können, was Programmdaten und systemweite Konfigurationsänderung und was User-spezifische Einstellungen sind.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ Dieser Beitrag wurde von Holger am 27.09.2005 um 17:14 Uhr editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

27.09.2005, 17:24 Uhr

Solar
Posts: 3680
Nutzer

Kurzer Einwurf a la Brainstorming:

Bei Gentoo Linux wird Software erst compiliert, dann in einer "Sandbox" installiert: Das System protokolliert mit, welche Operationen von der Installationsroutine ausgeführt werden, prüft sie auf ihre Zulässigkeit, und führt erst nach Abschluß der Sandbox-Installation die eigenliche Installation aus. Keine halbfertigen, aus Sicherheitsbedenken abgebrochenen Installationen oder übergebügelten Systemdateien mehr.

[ - Antworten - Zitieren - Direktlink - ]

27.09.2005, 17:39 Uhr

FischX
Posts: 436
Nutzer

Man kann unter X11 Arbeitsflächen Namen zuordnen also müsste man diese auch "anspringen" können

[ - Antworten - Zitieren - Direktlink - ]

27.09.2005, 23:15 Uhr

DrNOP
Posts: 4118
Nutzer

@Solar:
Hatten wir - naja, ansatzweise - auf dem Amiga doch auch? Der Installer bietet doch auch an
[ ] Pretend to install
[ ] Install for real
Das alles überprüfen und so mußte eben der Benutzer machen anhand des sicherlich erstellten Logfiles.
--
Es gibt keine Notbremse für all den technischen Humbug, mit dem wir unsere Zeit vertrödeln.

[ - Antworten - Zitieren - Direktlink - ]

27.09.2005, 23:16 Uhr

ylf
Posts: 4112
Nutzer

Zitat:
Original von NoImag:

Zitat:
Original von Holger:
Wenn eine Installationroutine nicht in der Lage ist, sich die nötigen Rechte per Dialog vom User einzuholen (einige beweisen, daß es geht),

Oder meinst du, für bestimmte Aufgaben wird jedesmal automatisch angefragt, ob du dazu berechtigt bist, so wie bei MacOS X?

Diese Verfahrensweise ist bei den diversen Linux-Distributionen
eigentlich seit Jahren üblich.

Zitat:
Allerdings gibt es auch bei MacOS X noch einen "root" und manchmal muss man sich als "root" einloggen.

Das ist mir neu. Bei OSX10.2.x kann man sich jedenfalls nicht als root einloggen, ohne am System zu manipulieren und muß das logischerweise auch nicht.

bye, ylf

[ Dieser Beitrag wurde von ylf am 27.09.2005 um 23:19 Uhr editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

27.09.2005, 23:43 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von DrNOP:
@Solar:
Hatten wir - naja, ansatzweise - auf dem Amiga doch auch? Der Installer bietet doch auch an
[ ] Pretend to install
[ ] Install for real
Das alles überprüfen und so mußte eben der Benutzer machen anhand des sicherlich erstellten Logfiles.

Ja, aber gerade das automatische Rückgängigmachen ist ja das besondere Feature, insbesondere, da auch auf dem Amiga die Möglichkeit zum De-Installieren sehr oft vom Entwickler vergessen wurde.
Die andere Sache ist die atomare Behandlungsweise. Eine Installation kann in diesem Szenario nur durchgeführt oder nicht durchgeführt sein, aber nicht halbfertig im System herumlungern.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

28.09.2005, 00:14 Uhr

FischX
Posts: 436
Nutzer

ein "must feature" ist auch das nach Bibliotheken ect auch im Programmverzeichniss gesucht wird, das erleichtert das ausführen von Programmen die sich auf einer CD oder einem USB-Stick befinden ungemein ohne das bei einer Installation libs etc doppelt abgelegt werden müssten.

[ - Antworten - Zitieren - Direktlink - ]

28.09.2005, 12:00 Uhr

schluckebier
Posts: 1059
Nutzer

Zitat:
Original von Holger:
Ob "zusätzliche" oder "neuere" APIs hängt natürlich im Einzelfall vom Ergebnis genau dieser Grundsatzdiskussion ab. Es ist natürlich immer besser, wenn ein Feature in die offizielle Code-Basis aufgenommen wird.

Klar. Ist halt nur die Frage, ob ein Embedded UAE tatäschlich in der offiziellen Code-Basis erwünscht wäre. Bei WM und Skins sehe ich da allerdings auch kein Problem.

Zitat:
Manchmal hilft es, den Amiga-Background nicht zu erwähnen, und einen an das gewohnte Linux-Umfeld angepaßten Namen zu verwenden.

Das halte ich auch für besser. ;o)

Zitat:
Klar, aber besser sind immer Dinge, die man auch Linux beilegen kann.

Das dürfte im Falle des Kickstarts leider unmöglich sein. Wenn es direkt beiliegen soll, führt kein Weg an einem nachprogrammierten Kickstart vorbei, was wiederum eine Heidenarbeit und entsprechend langwierig wäre.

Zitat:
Die meisten Distributionen versuchen immer alles, was man frei kriegen kann, zu integrieren und das erspart einem das Übersetzen von verschiedenen Versionen für die jeweilige Distri.

Emulatoren sind eigentlich bei jeder Distribution irgendwo erhältlich, natürlich ohne die benötigte Firmware. Da es dabei funktioniert, dürfte es auch bei einem separaten Aufsatz kein Problem geben.

Zitat:
/proc ist sowieso virtuell, /dev in einigen Systemen inzwischen auch, niemand sagt, daß die realen Pfade auf der Platte die sein müssen, die das System (egal ob GNU/Posix oder Amiga) sieht.
Welche tatsächlich auf der Platte sind, hängt vom Anwendungsfall ab. Bootet man Amithlon like und startet ab und zu mal ein Linux Programm kann das anders sein, als wenn man sein Linux-System bootet und ab und zu mal ein Amiga-Programm startet.

Also vereinfacht ausgedrückt soll sich das Dateisystem je nach vorhandenem Kontext anders darstellen? FSAL, File System Abstraction Layer? :o)

Je nachdem, welcher Ansatz verfolgt werden soll, halte ich das möglicherweise ;o) für Overkill. Wenn es nur darum geht, Amiga-Programme aus einer Linux-Umgebung heraus zu starten, reicht es völlig, wenn die benötigten FS-Strukturen und der ganze andere Klimbim nur für die Anwendung "sichtbar" sind, warum sollte ein Linuxer den Linux-Unterbau in Amiga-Manier sehen wollen? Was mich gleich zu einem neuen Problem bringt, nämlich einer entsprechenden Inkonsistenz im Verhalten des theoretischen Amiga-Aufsatzes:

Nehmen wir mal an, ich hätte z.B. Multiview über KDE angeklickt und das Programm macht dann wie gewünscht seinen Dateirequester auf. Die Pfade hätten dann das gewohnte Amiga-Format, was für Linux-User natürlich alles andere als schön ist (die sind ja auch eigen :o)). Das könnte man womöglich über einen ASL-Patch umbiegen, aber es gibt ja auch Programme mit selbstgeschnitzten Requestern usw.

Aber mein eigentliches Verständnisproblem geht noch viel tiefer, denn mir ist noch nicht so recht klar, wie es überhaupt machbar ist, die komplette Amiga-Umgebung parat zu haben, um eine einzelne Applikation im richtigen Kontext zu starten. Anders als bei leicht emulierbaren Systemen, die höchstens eine Firmware zum Starten haben (wie z.B. SNES), ist die Amiga-Umgebung ja doch relativ komplex und entsprechend unvorhersehbar. Nur ein Kickstart mit minimaler Workbench, was man beides ja locker im Speicher halten könnte, wird für die meisten Programme schlicht nicht reichen, es müsste hier mal eine Library installiert, dort mal eine Umgebungsvariable gesetzt sein, und und und... Was mich letztlich zu dem Schluss bringt, dass vor der Ausführung eines Programms tatsächlich erst das ganze Drumrum gebootet werden muss. Oder habe ich eine schöne, simple Lösung übersehen?

Zitat:
Hier treffen verschiedene Dinge aufeinander, die man zwar unabhängig voneinander betrachten könnte, deren Lösungen man aber genausogut hinterher in einer Distribution zusammenfassen könnte, die evtl. eine ziemlich runde Sache werden könnte.

Ich bin der Meinung, dass man sich auf eine Lösung konzentrieren sollte, sonst verzettelt sich alles. Wenn man die anderen möglichen Ansätze bei der Umsetzung im Hinterkopf behält und entsprechend umsichtig arbeitet, sollte eine spätere Erweiterung um andere Lösungsansätze durchaus machbar sein, oder?

Zitat:
Linux Programme mit Amiga Look&Feel ausführen
a) durch Desktop-Konfiguration, Skin, etc.

Für mich persönlich uninteressant (und ohne jeglichen Anspruch auf Allgemeingültigkeit, nicht, dass es wieder Streit gibt :o)).

Zitat:
b) durch funktionale Erweiterung der Linux-Toolkits

Dabei käme es dann auf die einzelnen Erweiterungen an, generell kann ich das weder besonders gut noch besonders schlecht finden. ;o)

Zitat:
alte Amiga-Programme integriert ausführen
a) durch einen minimalistischen Wrapper, der auf den Linux-Toolkits aufsetzt
b) durch einen UAE, der wesentlich transparenter als der bisherige läuft

Mein Favorit, eindeutig. Wobei ich halt das oben erwähnte Problem mit b) habe, weil ich mir derzeit keine Umschiffung der Klippen vorstellen kann.

Zitat:
Neuentwicklungen
a) AROS-like, auf einer x86-Version der Amiga-APIs, die hosted läuft
b) basierend auf den funktional erweiterten Toolkits aus Punkt 1b)

Angesichts der Flut von Amiga-Neuentwicklungen und der voraussichtlichen Zeit, die sowas in Anspruch nehmen würde, wäre das für mich höchstens ein Zukunftsprojekt (auch hier wieder ohne jeglichen Anspruch auf Allgemeingültigkeit, your mileage may vary).

[ - Antworten - Zitieren - Direktlink - ]

28.09.2005, 12:42 Uhr

ylf
Posts: 4112
Nutzer

Zitat:
Original von schluckebier:
Aber mein eigentliches Verständnisproblem geht noch viel tiefer, denn mir ist noch nicht so recht klar, wie es überhaupt machbar ist, die komplette Amiga-Umgebung parat zu haben, um eine einzelne Applikation im richtigen Kontext zu starten. Anders als bei leicht emulierbaren Systemen, die höchstens eine Firmware zum Starten haben (wie z.B. SNES), ist die Amiga-Umgebung ja doch relativ komplex und entsprechend unvorhersehbar. Nur ein Kickstart mit minimaler Workbench, was man beides ja locker im Speicher halten könnte, wird für die meisten Programme schlicht nicht reichen, es müsste hier mal eine Library installiert, dort mal eine Umgebungsvariable gesetzt sein, und und und... Was mich letztlich zu dem Schluss bringt, dass vor der Ausführung eines Programms tatsächlich erst das ganze Drumrum gebootet werden muss. Oder habe ich eine schöne, simple Lösung übersehen?

Also keiner hat gesagt, daß das simple wird. Wenn ich Holger richtig verstehe, dann schwebt ihm so etwas ähnliches wie bei MacOS vor, wo in OSX bei Bedarf ein OS9 in einer Sandbox, oder wie sich sowas im Fachchinesisch schimpft, gestartet wird.
In unserem Fall würde dies heißen, daß der UAE bei Bedarf automatisch ohne Dailog gestartet wird, dieser die Workbench bootet und das eigentlich vorher aufgerufene AmigaProgramm ausführt. Der UAE stellt ja in sich schon eine Sandbox dar. Das AmigaOS (3.x) wird einfach installiert bzw. wird der UAE bei der Erstinstallation entsprechend eingerichtet. Das funktioniert beim Mac genauso, bzw. kann OSX ein bereits installiertes OS9 übernehmen. Im Prinzip beschräkt sich die Problematik darauf, "Linux" bzw. dem Desktop beizubringen, Amiga-Programme von Linux-Programmen zu unterscheiden, was wohl recht leicht über das "Icon" lösbar wäre. Das Amiga-Programm ist dann eine Datei für die Anwendung UAE. Der UAE müßte lediglich das Amiga-Programm als Argument übergeben bekommen. Man könnte beim Beginn des UAE-Starts z.B. hingehen und das Amiga-Programm nach "Workbench:WBStartup" kopieren und beim Beenden wieder löschen. O.K., ist sicherlich ein böser Hack, müßte aber funktionieren. Das ließe sich ja sogar durch ein Script lösen, wenn man die Workbench in einem Verzeichnis installiert, was beim E-UAE sowieso die einzige Möglichkeit zur Zeit ist, wenn ich mich recht erinnere.
Also so kompliziert ist das ja doch nicht.

bye, ylf

[ - Antworten - Zitieren - Direktlink - ]

28.09.2005, 12:44 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von schluckebier:
Klar. Ist halt nur die Frage, ob ein Embedded UAE tatäschlich in der offiziellen Code-Basis erwünscht wäre. Bei WM und Skins sehe ich da allerdings auch kein Problem.

Das bezog sich ja auch auf einzelne Features, die zur Verbesserung der Linux-Umgebung implementiert werden. Wenn sie gleichzeitig dem API-Wrapper eines 68k-Emulators helfen, um so besser.

Zitat:
Das dürfte im Falle des Kickstarts leider unmöglich sein. Wenn es direkt beiliegen soll, führt kein Weg an einem nachprogrammierten Kickstart vorbei, was wiederum eine Heidenarbeit und entsprechend langwierig wäre.

Nachprogrammieren, ja. Im Falle eines minimalen Wrappers (ala Wine), der also auch nach und nach wachsen kann, ist das schon einfacher.

Zitat:
Also vereinfacht ausgedrückt soll sich das Dateisystem je nach vorhandenem Kontext anders darstellen? FSAL, File System Abstraction Layer? :o)

Das Dateisystem von Linux ist sowieso virtuell. Es ist nur gängige Praxis, das die meisten Verzeichnisstrukturen 1:1 einer Struktur auf der Festplatte entsprechen.

Zitat:
Nehmen wir mal an, ich hätte z.B. Multiview über KDE angeklickt und das Programm macht dann wie gewünscht seinen Dateirequester auf. Die Pfade hätten dann das gewohnte Amiga-Format, was für Linux-User natürlich alles andere als schön ist (die sind ja auch eigen :o)).

So eigen sind die auch wieder nicht, sonst würden die Desktop-Umgebungen ja auch nicht davon abweichen. Laß die A/Box ein ROOT: und ein HOME: Laufwerk haben, und alles ist bestens

Zitat:
Aber mein eigentliches Verständnisproblem geht noch viel tiefer, denn mir ist noch nicht so recht klar, wie es überhaupt machbar ist, die komplette Amiga-Umgebung parat zu haben, um eine einzelne Applikation im richtigen Kontext zu starten. ... Was mich letztlich zu dem Schluss bringt, dass vor der Ausführung eines Programms tatsächlich erst das ganze Drumrum gebootet werden muss. Oder habe ich eine schöne, simple Lösung übersehen?

Die meisten Anwendungen brauchen maximal ein paar Umgebungsvariablen und Assigns. Umgebungsvariablen haben auf dem Amiga sowieso Persistenz, das muß man auch unterstützen, und Assign kann man im Prinzip genauso unterstützen/erweitern.
Das AmigaOS kopiert normalerweise den Inhalt von ENVARC: nach ENV:, aber es gibt m.W. einen Patch, der stattdessen bei einem Zugriff auf ENV: in ENVARC: nachsieht, wenn es den Eintrag in ENV: nicht gibt.
Bei dieser Vorgehensweise braucht man das Kopieren zur Bootzeit nicht.

Zitat:
Ich bin der Meinung, dass man sich auf eine Lösung konzentrieren sollte, sonst verzettelt sich alles. Wenn man die anderen möglichen Ansätze bei der Umsetzung im Hinterkopf behält und entsprechend umsichtig arbeitet, sollte eine spätere Erweiterung um andere Lösungsansätze durchaus machbar sein, oder?

Darum geht's ja. Ich wüßte auch, worauf ich mich als erstes konzentrieren würde, aber das heißt nicht, daß nicht z.B. jemand parallel dazu Skins entwerfen könnte :o)

Zitat:
Zitat:
Linux Programme mit Amiga Look&Feel ausführen
a) durch Desktop-Konfiguration, Skin, etc.
Für mich persönlich uninteressant (und ohne jeglichen Anspruch auf Allgemeingültigkeit, nicht, dass es wieder Streit gibt :o)).

Aber auch am leichtesten zu realisieren.

Zitat:
Zitat:
b) durch funktionale Erweiterung der Linux-Toolkits
Dabei käme es dann auf die einzelnen Erweiterungen an, generell kann ich das weder besonders gut noch besonders schlecht finden. ;o)

Bedenke, daß das auch für den Ansatz eines minimalistischen Wrappers, der auf den Linux-Toolkits aufsetzt, von Bedeutung ist. Evtl. muß man sogar diesen Ansatz verfolgen, um den anderen zu realisieren.

Zitat:
Zitat:
alte Amiga-Programme integriert ausführen
a) durch einen minimalistischen Wrapper, der auf den Linux-Toolkits aufsetzt
b) durch einen UAE, der wesentlich transparenter als der bisherige läuft
Mein Favorit, eindeutig. Wobei ich halt das oben erwähnte Problem mit b) habe, weil ich mir derzeit keine Umschiffung der Klippen vorstellen kann.

Tja, a) bedeutet mehr arbeit, aber potentiell bessere Ergebnisse.

Zitat:
Zitat:
Neuentwicklungen ...
Angesichts der Flut von Amiga-Neuentwicklungen und der voraussichtlichen Zeit, die sowas in Anspruch nehmen würde, wäre das für mich höchstens ein Zukunftsprojekt

Definitiv Zukunftsmusik.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

28.09.2005, 12:58 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von ylf:
In unserem Fall würde dies heißen, daß der UAE bei Bedarf automatisch ohne Dailog gestartet wird, dieser die Workbench bootet und das eigentlich vorher aufgerufene AmigaProgramm ausführt.

Das wäre die b) Variante.

Zitat:
Im Prinzip beschräkt sich die Problematik darauf, "Linux" bzw. dem Desktop beizubringen, Amiga-Programme von Linux-Programmen zu unterscheiden, was wohl recht leicht über das "Icon" lösbar wäre.

Sie unterscheiden sich sowieso, daß eine ist ELF, das andere Amiga-Hunk. Das es m.W. auch eine Erweiterung gibt, mit der man Java-Anwendungen wie normale Linux-Programme starten kann, sollte so etwas auch für Amiga-Binaries möglich sein.

Zitat:
Man könnte beim Beginn des UAE-Starts z.B. hingehen und das Amiga-Programm nach "Workbench:WBStartup" kopieren und beim Beenden wieder löschen.

Einfacher wäre ein Programm in WBStartup, daß auf Befehle aus der externen Umgebung wartet und selbige dann ausführt. Das kann z.B. über einen lokalen Socket gehen. Dann kann der UAE auch im Hintergrund bleiben, wenn man mehrere Programm ausführen will.

Die eigentliche Herausforderung wäre eine P96-Layers Erweiterung, die X11 Fenster öffnen kann, statt in einem Framebuffer zu arbeiten.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

28.09.2005, 13:23 Uhr

FischX
Posts: 436
Nutzer

AFAIK gibt es ein Projekt das Kickstart für UAE nachprogrammiert, ein minimal Kikstart liegt ja UAE bei "and at least some demo disks are reported to run with it." klingt ja schon nicht schlecht :-) wenn es gelingt 68k AROS unter UAE mit diesem Kick zu starten währe schon viel gewonnen.

[ - Antworten - Zitieren - Direktlink - ]

28.09.2005, 13:27 Uhr

schluckebier
Posts: 1059
Nutzer

Zitat:
Original von Holger:
Nachprogrammieren, ja. Im Falle eines minimalen Wrappers (ala Wine), der also auch nach und nach wachsen kann, ist das schon einfacher.

So minimal wie Wine geht leider nicht, da ja nicht nur eine fremde API, sondern eben auch ein anderer Prozessor und zumindest rudimentär der Chipsatz nachgebildet werden muss.

Zitat:
Das Dateisystem von Linux ist sowieso virtuell. Es ist nur gängige Praxis, das die meisten Verzeichnisstrukturen 1:1 einer Struktur auf der Festplatte entsprechen.

Naja, streng betrachtet ist jedes Dateisystem virtuell. Aber es gibt halt bestimmte Muster, die eben dateisystemtypisch sind.

Abgesehen von der Struktur ist mir aber gerade noch ein problem eingefallen, z.B. sehe ich beim Slash auch einen Konflikt in der Bewegung innerhalb des Dateisystems -- "/foo" ist beim Amiga ein Verzeichnis hoch und dann foo, unter Linux aber das Verzeichnis foo im Root-Verzeichnis. Schwierig, schwierig.

Zitat:
Die meisten Anwendungen brauchen maximal ein paar Umgebungsvariablen und Assigns. Umgebungsvariablen haben auf dem Amiga sowieso Persistenz, das muß man auch unterstützen, und Assign kann man im Prinzip genauso unterstützen/erweitern.

Was ist mit Handlern, Libraries, Devices, Fonts?

Zitat:
Das AmigaOS kopiert normalerweise den Inhalt von ENVARC: nach ENV:, aber es gibt m.W. einen Patch, der stattdessen bei einem Zugriff auf ENV: in ENVARC: nachsieht, wenn es den Eintrag in ENV: nicht gibt.

Assign ENV: ENVARC: wäre ein recht einfacher Patch. :o)

Zitat:
Bei dieser Vorgehensweise braucht man das Kopieren zur Bootzeit nicht.

Das macht den Kohl aber normalerweise auch nicht mehr fett...

Mein Problem ist auch eher grundsätzlicher Natur, denn ums "Booten" der Amiga-Box dürfte man kaum herumkommen. Die Frage ist, ob man das einmal z.B. nach dem Einloggen macht, oder eben bei jedem Aufruf eines Amiga-Programms. Beides klingt nicht wirklich verlockend, der erste Ansatz würde zwangsläufig Ressourcen verbraten, auch wenn gar kein Amiga-Programm gestartet wird, der zweite hätte eine lange Ausführungszeit zur Folge. Vielleicht so, dass beim ersten Aufruf eines Amiga-Programms "gebootet" wird und die Ressourcen wieder freigegeben werden, wenn nach einer (einstellbaren?) Zeit nix Amiga-mäßiges mehr gemacht wurde?

Ich denke aber mal weiter darüber nach, das muss pfiffiger machbar sein. :o)

Zitat:
Darum geht's ja. Ich wüßte auch, worauf ich mich als erstes konzentrieren würde, aber das heißt nicht, daß nicht z.B. jemand parallel dazu Skins entwerfen könnte :o)

Worauf würdest du dich denn konzentrieren wollen?

EDIT: Wieder mal Zitate repariert. ;o)

[ Dieser Beitrag wurde von schluckebier am 28.09.2005 um 13:27 Uhr editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

28.09.2005, 14:29 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von schluckebier:
So minimal wie Wine geht leider nicht, da ja nicht nur eine fremde API, sondern eben auch ein anderer Prozessor und zumindest rudimentär der Chipsatz nachgebildet werden muss.

Die Emulation existiert ja schon; wobei ich den Chipsatz-Teil in einem Wrapper-Ansatz weglassen würde, zumindest anfangs.

Zitat:
Was ist mit Handlern, Libraries, Devices, Fonts?

Liegen meist in Verzeichnissen, wo sie dann auch gefunden werden. Brauchen i.A. also keine Initialisierung in einer Bootphase.

Zitat:
Assign ENV: ENVARC: wäre ein recht einfacher Patch. :o)

Assign ENV: ENVARC: ADD, bitteschön. Wenn man nach ENV: schreibt, soll es ja nicht automatisch persistent sein.

Zitat:
Zitat:
Bei dieser Vorgehensweise braucht man das Kopieren zur Bootzeit nicht.
Das macht den Kohl aber normalerweise auch nicht mehr fett...

Ging nicht um die Perfmormance, sondern die Option, ohne Bootvorgang auskommen zu können. Betrifft hauptsächlich die a) Variante, bei einenm UAE inkl. Kickstart kommt man nicht ums Booten herum.

Zitat:
Vielleicht so, dass beim ersten Aufruf eines Amiga-Programms "gebootet" wird und die Ressourcen wieder freigegeben werden, wenn nach einer (einstellbaren?) Zeit nix Amiga-mäßiges mehr gemacht wurde?

Das geht in die richtige Richtung, denke ich.

Zitat:
Worauf würdest du dich denn konzentrieren wollen?

Den Emulationsgedanken, entweder Wrapper Ansatz oder Hintergrund UAE. Da man sich für beides erstmal intensiv mit den UAE-sourcen beschäftigen muß, würde ich mich zum jetzigen Zeitpunkt noch nicht auf eine bestimmte Variante festlegen.
Kommt bald Urlaub, und das Wetter draußen wird schlechter...gute Voraussetzung für neue Projekte.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

28.09.2005, 15:28 Uhr

schluckebier
Posts: 1059
Nutzer

Zitat:
Original von Holger:
Die Emulation existiert ja schon;

Schon, aber der Trick ist ja gerade die sinnstiftende Verknüpfung mit der Umgebung, die es so ja noch nicht gibt. ;o)

Zitat:
wobei ich den Chipsatz-Teil in einem Wrapper-Ansatz weglassen würde, zumindest anfangs.

Kann man ja immer noch bei Bedarf nachrüsten, da hast du recht.

Zitat:
Liegen meist in Verzeichnissen, wo sie dann auch gefunden werden. Brauchen i.A. also keine Initialisierung in einer Bootphase.

Im folgenden Absatz gibst du selbst ein Beispiel, wo es eben nicht so ist. MUI z.B. macht auch ein Assign ADD, was ohne Booten halt nicht klappt. Oder nimm Reaction, dafür muss AddDataTypes REFRESH ausgeführt werden. Sowas meinte ich mit dem Drumrum, das für die Ausführung eines einzelnen Programms nötig sein kann.

Zitat:
Zitat:
Assign ENV: ENVARC: wäre ein recht einfacher Patch. :o)
Assign ENV: ENVARC: ADD, bitteschön. Wenn man nach ENV: schreibt, soll es ja nicht automatisch persistent sein.

Da war ein Grinsemann hintendran. :o)

Zitat:
Ging nicht um die Perfmormance, sondern die Option, ohne Bootvorgang auskommen zu können. Betrifft hauptsächlich die a) Variante, bei einenm UAE inkl. Kickstart kommt man nicht ums Booten herum.

Genau das war ja meine Schlussfolgerung, die mir Kopfschmerzen macht. Booten ist doof. ;o)

Zitat:
Den Emulationsgedanken, entweder Wrapper Ansatz oder Hintergrund UAE. Da man sich für beides erstmal intensiv mit den UAE-sourcen beschäftigen muß, würde ich mich zum jetzigen Zeitpunkt noch nicht auf eine bestimmte Variante festlegen.

Da mindestens die 68k-Emulation ja in beiden Fällen vorhanden sein muss, wird sich beides nur marginal unterscheiden, meinst du nicht? Selbst ein stark vereinfachter Wrapper ohne Unterstützung für Chipset-Abhängigkeiten usw. muss ja auch auf eine Amiga-Umgebung zurückgreifen können, rein softwareseitig gesehen. Das ist ja das große Problem, dass man ein Programm nicht isoliert betrachten kann mit einigen wenigen Betriebssystemaufrufen, sondern oft auch die passende Umgebung dazu benötigt.

Zitat:
Kommt bald Urlaub, und das Wetter draußen wird schlechter...gute Voraussetzung für neue Projekte.

Ich bin gespannt. :o)

[ - Antworten - Zitieren - Direktlink - ]

28.09.2005, 16:59 Uhr

NoImag
Posts: 1050
Nutzer

Zitat:
Original von ylf:
Diese Verfahrensweise ist bei den diversen Linux-Distributionen
eigentlich seit Jahren üblich.

Bei den Linux-Installationen, auf denen ich bis vor drei Jahren gearbeitet habe, ging das nicht. Aber um so besser, wenn das inzwischen komfortabler ist.

Zitat:
Das ist mir neu. Bei OSX10.2.x kann man sich jedenfalls nicht als root einloggen, ohne am System zu manipulieren ...

Der User "root" ist standardmäßig deaktiviert. Wenn du die Aktivierung als "am System manipulieren" bezeichnen willst, dann hast du recht.

Zitat:
... und muß das logischerweise auch nicht.

Es gibt Dateien, von denen MacOS X glaubt, dass sie dich nichts angehen. Wenn du diese manipulieren willst, dann geht das nur, wenn du "root" bist. Außerdem habe ich bei mir eine CD-ROM rumfliegen, bei der MacOS X fest davon überzeugt ist, dass deren Inhalt nur den "root" etwas angeht. Unter Windows und AmigaOS gibt es mit dieser CD-ROM keine Probleme.

Tschüß,

[ - Antworten - Zitieren - Direktlink - ]

28.09.2005, 17:03 Uhr

NoImag
Posts: 1050
Nutzer

Zitat:
Original von Holger:

Zitat:
Original von DrNOP:
@Solar:
Hatten wir - naja, ansatzweise - auf dem Amiga doch auch? Der Installer bietet doch auch an
[ ] Pretend to install
[ ] Install for real
Das alles überprüfen und so mußte eben der Benutzer machen anhand des sicherlich erstellten Logfiles.

Ja, aber gerade das automatische Rückgängigmachen ist ja das besondere Feature, insbesondere, da auch auf dem Amiga die Möglichkeit zum De-Installieren sehr oft vom Entwickler vergessen wurde.
Die andere Sache ist die atomare Behandlungsweise. Eine Installation kann in diesem Szenario nur durchgeführt oder nicht durchgeführt sein, aber nicht halbfertig im System herumlungern.

Hinzu kommt, dass viele Skripte so schlecht geschrieben sind, dass "Pretend to Install" nicht richtig funktioniert.

Was die Deinstallation betrifft: Bei vielen Amiga-Programmen reicht das Löschen des Programmverzeichnisses. Das sollte auch erhalten bleiben.

Tschüß,

[ - Antworten - Zitieren - Direktlink - ]

28.09.2005, 17:18 Uhr

ylf
Posts: 4112
Nutzer

Zitat:
Original von NoImag:

Zitat:
Original von ylf:
Diese Verfahrensweise ist bei den diversen Linux-Distributionen
eigentlich seit Jahren üblich.

Bei den Linux-Installationen, auf denen ich bis vor drei Jahren gearbeitet habe, ging das nicht. Aber um so besser, wenn das inzwischen komfortabler ist.

BTW:
Das ist seit RedHat 6.2 schon so. Die Version ist von Anfang 2000.
Kann aber sehr gut sein, daß die anderen Distributionen damit entsprechend später angefangen haben.
Wobei drei Jahre unter Linux eine lange Zeit (ca. sechs Versionssprünge) sind.

bye, ylf

[ - Antworten - Zitieren - Direktlink - ]

28.09.2005, 17:28 Uhr

ylf
Posts: 4112
Nutzer

Zitat:
Original von Holger:

Zitat:
Original von ylf:
Man könnte beim Beginn des UAE-Starts z.B. hingehen und das Amiga-Programm nach "Workbench:WBStartup" kopieren und beim Beenden wieder löschen.
Einfacher wäre ein Programm in WBStartup, daß auf Befehle aus der externen Umgebung wartet und selbige dann ausführt. Das kann z.B. über einen lokalen Socket gehen. Dann kann der UAE auch im Hintergrund bleiben, wenn man mehrere Programm ausführen will.

Das wäre natürlich eleganter. Ob das einfacher ist, kann ich nicht beurteilen. Wenn du sagst, daß ist kein Problem, dann machen wir das so.

Zitat:
Die eigentliche Herausforderung wäre eine P96-Layers Erweiterung, die X11 Fenster öffnen kann, statt in einem Framebuffer zu arbeiten.

Was ist in diesem Fall ein X11 Fenster?
Was ist in diesem Fall ein Framebuffer?

Framebuffer sagt mir nur etwas im Zusammenhang mit nicht wirklich unterstützter Grafikhardware etwas.

Oder meinst du damit, daß jedes gestartete Amigaprogramm sein eigenes X11-Fenster bekommt?

bye, ylf

[ - Antworten - Zitieren - Direktlink - ]

28.09.2005, 18:00 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von schluckebier:
Im folgenden Absatz gibst du selbst ein Beispiel, wo es eben nicht so ist. MUI z.B. macht auch ein Assign ADD, was ohne Booten halt nicht klappt. Oder nimm Reaction, dafür muss AddDataTypes REFRESH ausgeführt werden.

Wie gesagt, (aber vielleicht nicht ausführlich genug), für assigns würde ich eine ENV-ähnliche Lösung favorisieren, die ohne Skripte auskommt. AddDataTypes REFRESH braucht man für die originale datatypes.library, für die wrapper-version wär's überflüssig.

Zitat:
Da war ein Grinsemann hintendran. :o)

Trotzdem würde es funktionieren. :o)

Zitat:
Booten ist doof. ;o)

Deshalb lieber einen wrapper.

Zitat:
Da mindestens die 68k-Emulation ja in beiden Fällen vorhanden sein muss, wird sich beides nur marginal unterscheiden, meinst du nicht?

Nein, ich denke, die Unterschiede werden deutlich ausfallen.

Zitat:
Selbst ein stark vereinfachter Wrapper ohne Unterstützung für Chipset-Abhängigkeiten usw. muss ja auch auf eine Amiga-Umgebung zurückgreifen können, rein softwareseitig gesehen. Das ist ja das große Problem, dass man ein Programm nicht isoliert betrachten kann mit einigen wenigen Betriebssystemaufrufen, sondern oft auch die passende Umgebung dazu benötigt.

Ich glaube, daß man Programme auch isoliert betrachten kann. Ich würde mit meinen Lieblingprogrammen anfangen, und dann für weitere Programme voten lassen

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

1 -2- 3

[ - Beitrag schreiben - ]

amiga-news.de Forum > AROS und Amiga-Emulatoren > was braucht ein "AMINUX" ?

[ - Suche - Neue Beiträge - Registrieren - Login - ]