Kompilier-/Programmierparadigmen

[Florian Lohoff]

On Mon, Jan 13, 2003 at 06:34:30PM +0100, Patrick Willam wrote:
> > Die Sourcen sollten schon Dir gehören...
> 
> ....tun sie aber nicht. Unter /usr/src/linux ist alles nur
> -rw-r--r root:root  /  drwxr-xr-x root:root
> 
> SuSE halt, oder wie??

Die gehoeren root - Und nur root sollte auch kernel source modifizieren
sonst koennte man dein system auch als kompromittiert ansehen.

> Ich kann jetzt aber trotzdem nicht ganz einsehen, warum die *Kernel*-
> sourcen oder die *Kernel*config fuer irgendjemand anderen als root
> schreibbar sein sollten.

Sind sie doch oben auch nicht - Es gibt leute die es fuer sinnvoll
halten den kernel als user und im homedir zu compilen was durchaus geht
und sicherlich ok ist wenn dem user die selbe sicherheit wie "root" 
zugestanden wird.

> Wer, ausser dem SysAdmin, hat denn bitteschoen am Kernel was rum-
> zudrehen?

Der user - Der nicht zwangslaeufig root sein muss um arbeiten am system 
durchzufuehren. Es macht sogar sinn es meistens nicht zu sein. Wie oft
haben leute durch einen kleinen fehler rm -rf djkdj * eingegeben und
durch zufall war ein space hinengerutscht.

> Darueberhinaus kann ich genausowenig einsehen, dass ein Programm
> (in diesem Falle "make menuconfig") irgendwas zu schreiben haette,
> solange es mir nur ersteinmal [die aktuellen] Informationen anzeigen
> soll.

Was schreibt denn "make menuconfig" - Es compiled menuconfig und dann
liest es die ".config" im aktuellen verzeichnis im normalfall
/usr/src/linux.

> Der einzige Moment, in dem Programme etwas zu schreiben haben,
> ist der, in dem ich sage "speichern". Nicht vorher und nicht nachher.
> (hier: am Ende wenn ich ohne/nach Aenderungen sage "config speichern")
> 
> [Es sei denn, es handelt sich um einen _explizit_ als solchen gestarteten
> *und* _explizit_ dafuer konfigurieten Daemon-Prozess.]
> 
> Grundsaetzlich ist es _mein_ System, auf dem ich einem Prozess gestatte
> ablaufen zu duerfen.
> Und wenn ein Programm -- insbesondere ein interaktives -- dann meint,
> dass es *nicht* auf _meinen_ Befehl zum Speichern warten braeuchte,
> sondern _von_sich_aus_ auf die Idee kommt, etwas speichern zu wollen,
> dann hat es gefaelligst *vorher* um _meine_Erlaubnis_ zu bitten.

Schick nen patch an linus oder benutz kein make menuconfig - Ich wuerde
sagen das zeug "Works as designed"

> Und wenn man sich als Code-Erzeuger auch nur _etwas_ an die seit
> nunmehr 20 Jahren existierenden und etablierten Usability-Guides
> haelt, dann laesst man sein Programm nicht nur fragen, *ob* es
> etwas speichern darf, sondern auch *wo* es das tun darf. Und dann
> sollte das Programm auch *dort* speichern oder gar nicht.

Es handelt sich um SOURCECODE und ein BUILDSYSTEM fuer EIN EINZIGES
PROJEKT. Moechtest du auch das "make dep" dich fuer jede datei fragt wo
es die speichert ?

> ....und ja, ich weiss, dass "make menuconfig" kein "richtiges" Programm
> ist, sondern hier "make" fuer einen uneigentlichen Nutzen etwas zweck-
> entfremdet wird.
> Das tut IHMO der Aussage ueber das schlecht-implementiert-Sein keinen
> Abbruch. Es sollte moeglich sein, dieselbe Funktionalitaet unter Wahrung
> der o.g. Grundsaetze zu implementieren.

Es ist moeglich ja - Aber total hirnverbrannt - Die config datei
woanders zu speichern hat keinen tieferen sinn da das build system auf
die ".config" im /usr/src/linux oder sagen wir "root des build-trees" 
angewiesen ist.

> ....und ja, gerade weil man manchmal kurzfristig Programme nutzen muss?/
> moechte/soll, mit denen man sich nicht vorher detailliert auskennt, sollten
> Programme die o.g. Grundsaetze beherzigen.

Der grundsatz von dem gesamten build system des linux kernel 2.4 und
vorangegangen ist das es keine dateien AUSSERHALB des "build roots"
anfasst und DAS finde ich deutlich wichtiger.

> Vielleicht hat ja jemand eine Idee, wo bei mir da der Denkfehler steckt.
> Oder ist es nur meine Arroganz, von Programmen zu erwarten, dass sich
> diese gefaelligst an allgemein etablierte Gepflogenheiten halten?

Es ist kein herkoemmliches programm fuer user sondern ein build system
und DAS ist dein denkfehler.

Flo
-- 
Florian Lohoff                  flo at rfc822.org             +49-5201-669912
                        Heisenberg may have been here.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lug-owl.de/pipermail/linux/attachments/20030113/2c58b96d/attachment.sig>