Ein paar Fragen

Universe

Active Member
Yoo schönen guten Abend,


ich habe nun endlich die Zeit gefunden mich mehr mit FreeBSD zu Beschäftigen. Es macht wirklich sehr viel Spaß und die Dokumentation ist sehr nützlich. Weiters finde ich das alles logisch erklärt ist und bin einfach begeistert.

Folgende Fragen habe ich:
1. Die Lizensbestimmungen mancher Software verbietet ein Verbreiten in binärer Form. Diese Software muss als Quelltext ausgeliefert werden (steht im Handbuch).
Gibt es in den Ports ein File wo das drinnen steht? In Makefile habe ich sowas nicht gefunden.

2. Übernacht habe ich mein System nicht ausgeschaltet. Ich habe mich ledeglich überall ausgelogt und habe am Bildschirm ttyv0 gehabt. In der Früh endecke ich dann folgenden Satz:
Code:
ath0: bb hang detected (ox4), resetting
Was bedeutet das?

3. Falls mir ein Fehler beim Kompilieren passiert und die Software schon fertig ist, könnte man das praktisch Nachkompileren?

4. Zuerst wollte ich openbox als X verwenden (eigentlich noch immer). Dann wollte ich es als startx ausführen. Folgendermaßen bin ich vorgegangen:
Code:
%echo "exec /usr/local/etc/xdg/open-
       box/autostart.sh" > ~/.xinitrc
Leider ging das aber nicht! Weiß auch leider nicht was das output war.
Ein Kdm oder Gdm habe ich mir nicht installiert.
Wie wäre hier die logische Vorgehenweise, wenn ich eine openbox-session mit kde4 starten möchte?
Die Datei autostart.sh könnte ich mir selber zurecht legen, wie es in man beschrieben ist. Ich habe auch kurzfristig hier im Forum gestöbert und habe etwas mit .xsessions gefunden. Aja, jetzt fällt es mir ein. Das selbe habe ich dann auch mit .xsession versucht. Ging aber auch nicht.

5. Nicht das ich unbedingt auf 3D abfahre, aber ich glaube das dadurch, wenn die Grakka besser "verstanden" wird, die CPU-Auslastung niedriger wäre, bei bestimmten Fällen(?). Meine Grakka ist eine ATI RADEON 5000 Serie.
Welchen Port soll ich hier bauen?

6. Unter /usr/ports/www/chromium/Makefile steht unter COMMENT= A mostly BSD-licensed web browser.
Warum mostly?

7. Vielleicht eine etwas dumme Frage: Gelten die ganz Normalen EULA’s beim Opera-Browser wenn ich sie mir an meinem Computer übersetze?

8. Dadurch resultiert meine 8te Frage. Woher oder woran erkenne ich in den ports was Open Source ist und was nicht?

9. Gibt es vielleicht eine Manpage zu Wildcats?


Vielen Dank und eine angenehme Nacht!

MfG
John
 
Zuletzt bearbeitet:
Guten Morgen. Dann fange ich mal an :)

1. Das ist ein Flag im Makefile. Schaust du hier: http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/porting-restrictions.html

2. Das heißt nur, dass die WLAN-Karte sich verkackt hatte und vom Treiber wiederbelebt wurde. Das kommt vor und ist nicht weiter schlimm. Der Atheros-Treiber ist auch einer derjenigen, die ständig im Fluss sind. Daher ist er im Prinzip bereits veraltet, wenn ein RELEASE erscheint, aber auf irgendwelche Entwicklerversionen würde ich dafür dennoch nicht updaten.

3. Ich verstehe die Frage nicht.

4. Bei mir heißt die Datei "autostart" ohne ".sh" am Ende. :) Allerdings nutze ich das Script nicht, sondern starte Openbox direkt, da ich es ohne Desktopumgebung nutze.

5. Die HD5000-Serie wird von FreeBSDs X.org nicht unterstützt. 3D ist daher nicht möglich.

6. Weil Teile vom Chromium unter MPL und LGPL stehen.

7. Ja. Lizenzbedingungen gelten immer, außer du schließt ein eigenes Lizenzabkommen mit dem Hersteller einer Software ab. Opera wird übrigens nicht übersetzt, es ist und bleibt eine fertig gebaute Binary. Der Quellcode ist nicht verfügbar.

8. An der Lizenz. Das LICENSE-Framework der Ports ist hier erklärt: http://wiki.freebsd.org/PortsLicenseInfrastructure

9. Hm?
 
4. Bei mir heißt die Datei "autostart" ohne ".sh" am Ende. :) Allerdings nutze ich das Script nicht, sondern starte Openbox direkt, da ich es ohne Desktopumgebung nutze.

Kurze Frage dazu, das bedeutet, du hast dein Setup nicht in autostart sondern in deiner xinitrc stehen oder wie machst du das?
Ich meine so Scherze die man bei einem Desktop Setup haben will, wie Hintergrundbildchen oder Taskbar.
 
Du kannst im Prinzip wie ein Shellscript das rein schreiben was du willst: Bei mir steht zb. folgendes drin:

Code:
xrdb -merge $HOME/.Xresources

feh --bg-scale $HOME/.family.jpg
DISPLAY=:0.1 feh --bg-scale $HOME/.family_1920x1200.png

numlockx
xmodmap .Xmodmap

DISPLAY=:0.1 conky &

openbox-session &
DISPLAY=:0.1 openbox-session
Das ist ein dual-head setup mit seperated X windows. Als erstes vereinigt es die resource db, dann setzt es jeweils das Hintergrundbild auf den verschiedenen Monitoren, aktiviert den numlock liest mein key mapping ein, startet auf einem Monitor conky und dann 2 openbox sessions. In der openbox autostart, steht dann noch ein bisschen anderes Zeugs drin.
 
Die Funktionsweise kannte ich schon, ich interessiere mich nur dafür wie es andere machen. Ich denke, ich bin sehr nah am DAU Setup und nutze die autostart geschichte und die rc und menu XMLs. gestartet wird das alles dann über slim ( also eigentlich xinitrc).

Danke das du mir dein Setup erklärt hast s-tlk! :)
 
Als (Not)Lösung habe ich openbox folgendermaßen zum Starten gebracht. echo "exex openbox-session" > ~/.xinitrc

In "man openbox" habe ich vier Möglichkeiten gelesen, wie man openbox Starten kann.
 
Ich mache es schon seit Jahren so:
Code:
#!/bin/sh

# Xdefaults einsaugen
/usr/local/bin/xrdb -merge ~/.Xdefaults

# Maus
/usr/local/bin/xset m 5 1

# numlockx
/usr/local/bin/numlockx & 

# Rechte fuer Xscreensaver
/usr/local/bin/xhost +localhost

# Xscreensaver
/usr/local/bin/xscreensaver -no-splash &
 
# Hintergrund
/usr/local/bin/nitrogen --restore &

# Tint
/usr/local/bin/tint2 &

# Terminal
/usr/local/bin/urxvtd -q -o -f &
 
# Openbox
/usr/local/bin/openbox &
WMPID=$!

# Auf das Ende der Sitzung warten
wait $WMPID

# XScreensaver töten
/usr/local/bin/xscreensaver-command -exit

# 2 Sek warten und schluss
sleep 2
clear
 
Zur Frage 3: Ich meinte das einmal gebaute Port rekonfigurieren, ob das moeglich ist. Aus dem Handbuch geht hervor, dass es moeglich ist.

Zur Frage 6: Ja das ist jetzt einleuchtend. Wenn ich naemlich mit FreeBSD ein Programm schreiben wuerde, dann muesste ich den Quellcode auch nicht veroeffentlichen. Und das kommt dem Chromium Browser von Google bei FreeBSD am aehnlichsten, darum mostly. Darum auch unter BSD, LGPL21 und MPL.

Zur Frage 9: Lol :ugly: ich meinte eigenlich, ob es eventuell Manpages fuer Wildcards gibt? Oder vielleicht etwas besser gefragt: Gibt es HOWTOS wo zum Beispiel Themen wie "Suchmuster fuer Datein" behandelt werden?

Danke fuer die Antworten!

EDIT:
Zur Frage 4: In der Manpage ist aber von "autostart.sh" die Rede. Jetzt bin ich ein bischen verwirrt.

Zur Frage 5: Gibt es da vielleicht eine Begruendung von FreeBSD, warum diese Grakka nicht 3D kann?
 
Zuletzt bearbeitet:
Zur Frage 3: Ich meinte das einmal gebaute Port rekonfigurieren, ob das moeglich ist. Aus dem Handbuch geht hervor, dass es moeglich ist.
"make config" im Portsdirectory.

Zur Frage 6: ... Wenn ich naemlich mit FreeBSD ein Programm schreiben wuerde, dann muesste ich den Quellcode auch nicht veroeffentlichen.
Falsch. Wenn du ein Programm schreibst, legst du fest welche Lizenz für dein Programm gültig ist.
Auf welchem OS der Editor läuft, in dem du den Quelltext eintippst, ist egal.


Zur Frage 9: Lol :ugly: ich meinte eigenlich, ob es eventuell Manpages fuer Wildcards gibt? Oder vielleicht etwas besser gefragt: Gibt es HOWTOS wo zum Beispiel Themen wie "Suchmuster fuer Datein" behandelt werden?
Im Falle der Standardshell "tcsh", wäre das in der Manpage zur tcsh unter "Filename substitution" zu finden.
 
Zur Frage 4: In der Manpage ist aber von "autostart.sh" die Rede. Jetzt bin ich ein bischen verwirrt.

Zur Frage 5: Gibt es da vielleicht eine Begruendung von FreeBSD, warum diese Grakka nicht 3D kann?

Zu Frage 4: Ich tippe auf einen Schreibfehler oder die Datei wurde umbenannt, könntest das ja als Bug melden :)

Zu 5: Das Problem ist die mangelnde Dokumentation der ATI GraKas seitens AMD, bzw. das Fehlen eines Binär Treibers so wie es Ihn z.b. von Nvidia gibt. Aber ich habe gelesen, dass AMD sich an dem Linuxkernel (oder war es der X) Treiber beteiligt. Sollte AMD nicht tatsächlich pleite gehen so wie es einige zeit aussah, könnte es eine Verbesserung der Unterstützung geben.
 
Besten Dank fuer die Antworten noch einmal!

@WIedmann: Hmm... danke sehr zur Frage 6. Deine Antwort ist sehr aufschlussreich!
Bedeutet das praktisch, dass ich unter Windows, wenn ich es koennte, genauso gut Programmieren koennte, nur das die von mir geschriebene Software auf dem Windows nicht so gut fuer Testgebraeuche zur Verwendung waere (weil Windows Closed Source ist)?
Bedeutet dass eigentlich, desto mehr mein Sytem offen ist, sprich Quell Code, selber kompilieren und vielleicht vieles mehr keine Ahnung, desto mehr kann ich meine geschriebene Software auf meinem System dann testen? Bei einem Linux waere das ja meistens nicht der Fall, Ausnahme Gentoo und ich glaube auch bei LFS, dass dort mehr Einschraenkungen gegeben sind?
Ist das vielleicht ein weiterer Vorteil, wenn man direkt aus dem Quell Code alles selber kompiliert, dass man dann seine eigene geschriebene Software besser testen kann wie es auf verschiedene Situationen und Datein und keine Ahnung leider :-( reagiert und ich dann so besser Anpassungen taetigen koennte?


Zur Frage 5 bezueglich Grakka:
http://wiki.freebsd.org/DriDrivers

Sorry fuer die vielen Fragen. Das war dann auch meine Letzte, versprochen. :)

MfG
John
 
Ich mache es schon seit Jahren so:
Code:
#!/bin/sh

# Xdefaults einsaugen
/usr/local/bin/xrdb -merge ~/.Xdefaults

# Maus
/usr/local/bin/xset m 5 1

# numlockx
/usr/local/bin/numlockx & 

# Rechte fuer Xscreensaver
/usr/local/bin/xhost +localhost

# Xscreensaver
/usr/local/bin/xscreensaver -no-splash &
 
# Hintergrund
/usr/local/bin/nitrogen --restore &

Hm, hat schon so seine Vorteile alles in der .xinitrc zu lassen, dann spart man das suchen wo die Bestandteile des Desktops gestartet werden. Obwohl man das in der man auch lesen könnte. Mal schauen ob ich das nich mal ändere.

Danke auch für deinen Lösungsansatz Yamagi! :)
 
Bedeutet dass eigentlich, desto mehr mein Sytem offen ist, sprich Quell Code, selber kompilieren und vielleicht vieles mehr keine Ahnung, desto mehr kann ich meine geschriebene Software auf meinem System dann testen? Bei einem Linux waere das ja meistens nicht der Fall, Ausnahme Gentoo und ich glaube auch bei LFS, dass dort mehr Einschraenkungen gegeben sind?
Ist das vielleicht ein weiterer Vorteil, wenn man direkt aus dem Quell Code alles selber kompiliert, dass man dann seine eigene geschriebene Software besser testen kann wie es auf verschiedene Situationen und Datein und keine Ahnung leider :-( reagiert und ich dann so besser Anpassungen taetigen koennte?

Also ich gebe zu ich verstehe deine Frage nicht so ganz... Wenn du ganz normale Anwederprogramme schreiben willst ist es eigentlich völlig egal was für ein System du drunter sitzen hast. Klar ist natürlich, dass du dein Programm für das System übersetzen musst auf dem du es laufen lassen willst (und falls du externe Libs oder irgendwas verwenden willst müssen die auch auf der Plattform laufen). Ob du dein System aus den Quellen übersetzt und installierst oder eben direkt die übersetzten binarys installierst hat damit rein gar nichts zu tun... Denn was am Ende läuft ist eh binär... Was willst du denn für software schreiben... und wie willst du sie testen? ^^

Anders sieht die Sache natürlich aus wenn du diekt am System werkeln willst (als z.B. das FreeBSD-Team unterstüzten). Dann ist es natürlich notwendig die Systemquellen zu haben.. Aber ob du dein System aus den Quellen übersetzt oder fertig installiert hast ist auch hier völlig egal. Und am Rande erwähnt bekommst du zu jedem Linux das du installierst auch die Quellen wenn du sie willst...
 
Also ich gebe zu ich verstehe deine Frage nicht so ganz... Wenn du ganz normale Anwederprogramme schreiben willst ist es eigentlich völlig egal was für ein System du drunter sitzen hast. Klar ist natürlich, dass du dein Programm für das System übersetzen musst auf dem du es laufen lassen willst (und falls du externe Libs oder irgendwas verwenden willst müssen die auch auf der Plattform laufen). Ob du dein System aus den Quellen übersetzt und installierst oder eben direkt die übersetzten binarys installierst hat damit rein gar nichts zu tun... Denn was am Ende läuft ist eh binär... Was willst du denn für software schreiben... und wie willst du sie testen? ^^

Anders sieht die Sache natürlich aus wenn du diekt am System werkeln willst (als z.B. das FreeBSD-Team unterstüzten). Dann ist es natürlich notwendig die Systemquellen zu haben.. Aber ob du dein System aus den Quellen übersetzt oder fertig installiert hast ist auch hier völlig egal. Und am Rande erwähnt bekommst du zu jedem Linux das du installierst auch die Quellen wenn du sie willst...

Leider bin ich noch nicht soweit das ich irgendeine Programmiersprache erlernt habe.

Vielleicht nur am Rande: Ich habe mir zum Ziel gesetzt FreeBSD zum Laufen zu bringen. Sobald das passiert ist, werde ich mich mehr mit UNIX oder UNIX-like beschaeftigen wie z.B. die ganzen HOWTOS durcharbeiten, manpages ebenso und alles was mir unter den Finger kommt. Sobald ich das habe, moechte ich versuchen nach der Reihenfolge die Html, Python und C und vielleicht C++ Sprachen so gut es geht zu erlernen. Hoffentlich halte ich das auch durch :)

Mein Gedankengang war hierbei, dass man Software schreibt, vielleicht in C od. C++ die das Arbeiten am meinen FreeBSD System erleichtert, also quasi sowas wie Erweiterungen... .

Vielleicht kann man als Entwickler bei GNU/Linux die vorkompilierte Software mit der von dem User geschriebenen Software nicht so gut testen, weil alles schon binaer ist. Und wenn ich dann mit mit FreeBSD meine geschriebene Software z.B. mit Rednotebook testen moechte, dann wuerde es wahrscheinlich mehr Sinn machen, wenn ich "flexibel" Rednotebook kompilieren und rekompilieren koennte, und dann gucken wie sich die Software in verschiedene Situationen zur meiner Software verhaelt usw. .
 
Steifes Programm... Viel Erfolg.

Aber es ist wie gesagt völlig egal welche Umgebung du verwendest. Du kannst unter Windows genauso programmieren.
Hmm.... Ich will nicht unhöflich wirken, aber evtl solltest du dich erst etwas tiefer in die Materie einarbeiten... Mal die ersten 10 kleine Progrämmchen geschrieben haben... Bevor du dir Gedanken darüber machst wie sich deine Programme im Systemumfeld verhalten. Ich denke viele Fragen werden sich auf dem Weg erledigen ;)
 
Aber ich habe gelesen, dass AMD sich an dem Linuxkernel (oder war es der X) Treiber beteiligt. Sollte AMD nicht tatsächlich pleite gehen so wie es einige zeit aussah, könnte es eine Verbesserung der Unterstützung geben.

In einer der letzten Heise Zeitschriften war eine Meldung drin, dass AMD alle Programmierer von der Linux Unterstützung abgezogen (und entlassen) hat.
Von daher denke ich, dass sich hier auf absehbare Zeit nichts mehr tun wird.

Mario
 
Zurück
Oben