Kompilier-/Programmierparadigmen

[Patrick Willam]

Jan-Benedict schrieb:
> On Mon, 2003-01-13 18:34:30 +0100, Patrick Willam <p.willam at gmx.de>
> wrote in message <4330.1042479270 at www17.gmx.net>:
> > Jan-Benedict schrieb:
> > > On Mon, 2003-01-13 16:46:07 +0100, Patrick Willam <p.willam at gmx.de>
> > > wrote in message <9052.1042472767 at www17.gmx.net>:
> > > >
> > > > na dann wolln mer mal...
> > > > $> cd /usr/src/linux
> > > > $> make menuconfig
> > > > rm -f include/asm
> > > > rm: cannot unlink `include/asm': Keine Berechtigung
> > > > make: *** [symlinks] Error 1
> > > > $> su
> > > > #> make menuconfig
> > > 
> > > Die Sourcen sollten schon Dir gehören...
> > > *shrugger* So kann man sich gut Würmer installieren lassen. Siehe
> > > tcpdump/sendmail/libpcap/... Als user compiled sich's einfach
> > > besser...

Ich wollte mir aber gar nichts kompilieren; ich wollte ja nur diese Liste
angezeigt bekommen, damit ich nach der Treiberbezeichnung gucken kann.

> ...und selbst der [SysAdmin] sollte das unter seiner *privaten* UID
> machen, *nicht* als root.

_Sollte_; konnte ich aber dort (/usr/src/linux) nicht. Und /usr/src/linux
"mal eben" jemanden anders als root zu uebereignen halte ich auch nicht
fuer eine optimale Loesung.
  Ich wollte nur den von dir vorgeschlagenen Befehl benutzen, um an die
angefragte Information zu kommen. Mit dem Verlaufsprotokoll sollte
man nachvollziehen koennen was ich gemacht habe, damit man ggf.
den Fehler sieht warum der besagte Treiber nicht gelistet wurde.
  Um bloss kurz eine Information abzufragen werde ich jedenfalls nicht
noch vorher "mal nebenbei" das Rechtesystem auf dem Rechner (der
nicht meiner ist!) umstricken.
  Und selbst wenn ich es taete, haette ich als Nicht-Experte bestimmt
mehr Schaden als Nutzen.

Vorschlag zur Guete: Meintest du vielleicht sowas in der Art von
  $~> cp -r /usr/src/linux .
  $~> cd linux
  $~> make menuconfig
?

> Wenn Du als root arbeitest, dann mußt Du Dich bei *jedem* Befehl fragen:
> "_Muß_ ich dazu root sein?" Wenn Du das verneinen kannst,
> dann lautet die folgerichtige Antwort: Ctrl-D.

In diesem Falle musste ich dazu root sein (drwxr-xr-x root:root).
Abgesehen davon: Als Experte weis man natuerlich *wann* man *wo*
root sein _muss_. Als Nicht-Experte weiss ich das nur bei Wenigem.
Bei den meisten (fraglichen) Sachen stelle ich nur fest: _es_geht_nicht_
wenn ich nicht root bin.
Als Nicht-Experte bin ich darueberhinaus genauso entfernt davon zu
wissen, wie ich diese fraglichen Sachen so umbiegen kann (wie z.B.
oben), dass ich _doch_nicht_ root sein _muss_.

> Das Programm will erstmal (re-)kompiliert werden,

ich wollte nix kompilieren; s.o.

> wobei eine menge temporärer Dateien angelegt werden.

welche generell nach $TMP gehoeren (oder etwa nicht?!)

> Erstmal brauchst Du ein Programm zum konfigurieren Deiner
> Kernel-Sourcen, und das will irgendwo hingeschrieben werden. ...und ich
> finde es gut, daß es sich _nicht_ nach /usr/local/bin oder so
> installieren will.
> 
> > ...und ja, ich weiss, dass "make menuconfig" kein "richtiges" Programm
> > ist, sondern hier "make" fuer einen uneigentlichen Nutzen etwas zweck-
> > entfremdet wird.
> 
> Hae? Da wird brav compiled, um das Frontend zu erhalten. Darin fließen
> zwischedurch die Konfig-Soucen des Kernels ein, und dazwischen gibt's
> Abhängigkeiten. Das ist die Aufgabe von make: Abhängigkeiten zu
> verwalten. ...nicht unbedingt von Source Code.

_*"Frontend"*_ ist ein gutes Stichwort!!!

a)
Aufgabe von make::
* Abhaengigkeiten zu verwalten: OK
* Frontend zu sein: ?? (

b)
Ich wollte nix kompilieren (s.o.), ich wollte nur etwas einsehen.
Gerne mit grep oder find, gerne auch mit einem _Front_end.
  Das Frontend hat dann aber bitteschoen kompiliert zu sein oder wird
meinetwegen auch interpretiert; jedenfalls mit rein lesenden Zugriff
auf das _Back_end, -- oder wenn es in drei Teufels Namen etwas zu
schreiben hat, dann bitte in $TMP oder $HOME.
...Und dann gehoert es auch nach /usr/local/bin (oder so) installiert.
(Dass ich es nur als root dorthin installieren kann ist klar; aber
benutzen moechte ich es als nicht-root.)

> Wenn das Programm bereits vorhanden ist, dann kann es sich halten,
> woran es mag.

Diese Sichtweise halte ich fuer mindestens genauso arrogant.
Darueberhinaus: quod erat demonstrandum (was zu beweisen waere).
Wenn das ein funktionierendes oder auch nur brauchbares Paradigma
waere, dann braeuchten wir bis heute kein preemptives Multitasking,
keinen geschuetzten Speicher, keine virtuellen Devices, usw. usw. usw.

Wenn du dein obiges Statement _wirklich_ fuer der Weisheit letzten
Schluss haelst, dann solltest du -- so moechte ich etwas ueberspitzt
formulieren -- ausschliesslich MS-Programme verwenden. Die halten
sich naemlich auch nur an das, was sie moegen.

[Ich glaube, dass ich dich hier etwas ueberinterpretiere. Jedoch:
dieses Statement war ne wirkliche Steilvorlage.]

> Wenn es erst noch erstellt werden muß, dann muß man ihm Raum
> dazu lassen.

Richtig. Aber irgendwann muss es auch mal fertig werden. Ich bin da
Anhaenger der Knuthschen Ideologie, dass dies auch fuer so etwas
wie Software prinzipiell moeglich ist.

"make menuconfig" gibt es auch nicht erst seit gestern; aber wie dem
auch sei, es muss ja nicht "make menuconfig" sein.

** Die eigentliche Frage bleibt: **
> > gibt es noch _andere_ Programme im Kernel-Kompilierungs-Umfeld,
> > mit denen man dasselbe machen kann wie "make menuconfig",
> > die sich aber an die o.g. Massgaben halten?
oder etwas spezifischer:
"Wie kann ich als nicht-root Kernelkonfigurationsoptionen und/oder
Treibernamen/-beschreibungen uebersichtlich und fuer einen Nicht-
Experten geordnet einsehen, _ggf_ aendern und die geaenderten
Optionen auf Verlangen an einen Ort meiner Wahl oder auch gar nicht
speichern?"

Danke und Gruss,
Patrick

-- 
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!